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I.  INTRODUCTION 


A.  BACKGROUND 

In  July  1985,  the  Chief  of  Naval  Operations  (CNO)  promulgated  a  procedure  to  all 
naval  commands  which  required  the  originators  of  all  narrative  messages  to  determine 
if  a  message  is  administrative  or  operational  in  nature.  The  annotation  of  the  message 
type  on  the  message  would  permit  the  Fleet  Commander-in-Chief(FLTCINC),  through 
the  Naval  Communication  Area  Master  Station  (NAVCAMS),  to  remove  administrative 
messages  from  the  Fleet  Broadcast  channels  should  message  traffic  loading  warrant. 

In  June  1986,  Commander,  Naval  Telecommunications  Command  (CNTC),  issued 
management  guidelines  for  the  administrative  message  intercept  capability.  CNTC  also 
requested  comments  and/or  recommendations  from  the  NAVCAMS  concerning  the 
guidelines.  The  responses  from  the  NAVCAMS  was  generally  negative  and  dealt  with 
key  issues.  One  key  issue  was  the  failure  of  the  CNTC  guidance  to  consider  the  oper¬ 
ating  environments  and  the  special  needs  required  when  operating  in  these  environ¬ 
ments.  Another  issue  dealt  with  infringement  on  the  NAVCAMS'  control  of  traffic 
management;  the  issuance  of  a  set  policy/ guideline  on  the  implementation  of  adminis¬ 
trative  intercepts  restricts  the  NAVCAMS  from  fully  utilizing  all  local  expertise  and  re¬ 
sources  available.  Finally,  the  effectiveness  and  efficiency  of  the  administrative  intercept 
was  questioned;  specifically,  questions  were  raised  on  the  value  of  the  intercept  in  its 
present  form. 

B.  OBJECTIVES  AND  RESEARCH  QUESTIONS 

This  thesis  has  multiple  objectives;  the  first  objective  is  to  present  the  concept  of  the 
administrative  message  intercept  and  to  examine  the  capabilities  of  the  intercept.  Ad¬ 
ditionally,  the  responses  from  the  NAVCAMS  will  be  examined  to  consider  the  validity 
of  their  claims.  This  study  will  also,  through  the  use  of  a  computer  simulation  system, 
investigate  the  efTects  of  different  traffic  characteristics  on  the  effectiveness  of  the  inter¬ 
cept.  From  this  simulation  it  is  hoped  to  present  a  more  complete  set  of  considerations 
for  activating  an  intercept. 

C.  SCOPE 

The  research  conducted  in  this  thesis  focuses  upon  the  Fleet  Broadcast  sections  of 
the  Naval  Communications  Processing  and  Routing  System  (NAVCOMPARS).  Using 


the  General  Purpose  Simulation  System  V,  a  simple  model  of  a  single  output  channel 
of  the  Fleet  Broadcast  is  simulated.  Due  to  the  lack  of  historical  data  and/or  actual 
NAVCOMPARS  operation  time,  the  model  did  not  receive  full  validation  via  compar¬ 
ison.  However,  it  is  felt  that  the  model  does  portray  similar  behavior,  in  terms  of  output, 
to  provide  beneficial  data  for  analysis.  It  is  further  felt  that  this  model  and  its  results 
can  serve  as  a  foundation  for  future  study  in  this  particular  area  of  Naval  Communi¬ 
cations. 

D.  ORGANIZATION  OF  STUDY 

The  first  chapter  of  this  research  provides  a  brief  introduction  into  the  issues  con¬ 
cerning  the  implementation  of  an  administrative  message  intercept.  This  chapter  also 
points  out  the  objectives  and  research  questions  emphasized.  The  second  chapter  ex¬ 
amines  both  the  concept  and  mechanics  of  the  administrative  message  intercept.  The 
third  chapter  presents  a  review  of  factors  to  be  considered  when  forming  a  decision  on 
activating  an  intercept;  the  chapter  also  provides  a  summary  of  CNTC's  guidance  and 
the  responses  submitted  by  the  individual  NAVCAMS.  Chapter  IV  details  the  General 
Purpose  Simulation  System  V  and  presents  the  model  of  the  Fleet  Broadcast  output 
channel  used.  Chapter  V  is  a  presentation  and  discussion  of  simulation  results.  Chapter 
VI  is  a  proposed  decision  making  process  for  both  the  policy  maker  and  the 
operator/manager.  The  final  chapter  concludes  with  recommendations  and  suggested 
future  topics  of  research. 


II.  NAVCOMPARS  -  ADMINISTRATIVE  TRAFFIC  INTERCEPT  MODE 

A.  INTRODUCTION 

Within  the  Naval  Communications  Processing  and  Routing  System 
(NAVCOMPARS).l  intercept  of  administrative  message  traffic  is  only  one  of  many 
traffic  control  methods  available  to  the  system  operator.  In  this  chapter  the  following 
topics  will  be  discussed: 

1.  Fleet  Multichannel  Broadcast  System 

2.  Administrative  Traffic  Intercept 

3.  Administrative  Traffic  Intercept  Modes 

4.  Message  Reentry  Modes 

B.  FLEET  MULTICHANNEL  BROADCAST  SYSTEM 

The  Fleet  Multichannel  Broadcast  System  (MULCAST)  serves  as  the  United  States 
Navy's  primary  method  of  sending  general  service  (genser)  message  traffic  between 
forces  afloat  and  the  Naval  Telecommunications  System  (NTS).  The  Multichannel 
Broadcast  is  a  non-termination2  system  capable  of  being  received  by  properly  equipped 
and  frequency  aligned  units. 

The  Multichannel  Broadcast  is  primarily  operated  through  two  transmission  sys¬ 
tems: 

1.  Fleet  Satellite  Broadcast  (FSB)  System 

2.  High  Frequency  Broadcast  (HFB)  System 

1.  Fleet  Satellite  Broadcast  (FSB)  System 

The  Fleet  Satellite  Broadcast  serves  as  the  primary  method  of  transmitting  the 
Multichannel  Broadcast.  The  FSB's  normal  configuration  requires  a  one  channel  as¬ 
signment  for  uplink  and  downlink  from  one  of  the  U.S.  Navy's  satellite  communication 
systems  (i.e.  Fleet  Satellite  Communications  System  (FLTSATCOM),  Gapfiller  System, 
Leased  Satellite  System  (LEASAT)).  Using  multiplexing  technology,  sixteen  individual 

1  For  a  detailed  summary  of  NAVCOMPARS  see  Appendix  A. 

2  A  termination  is  a  special  full-time  dedicated  circuit  between  a  fleet  unit  and  the  NTS. 
Terminations  are  usually  required  because  of  high  traffic  flow  due  to  major  exercises/operations, 
special  operations,  or  command  requirements. 


channels  comprising  the  Multichannel  Broadcast  are  combined  into  a  single  1200  Baud 
FSB  channel  for  uplink  to  the  system  satellite.  The  sixteen  channels  include: 

•  11-75  Baud  general  service  teletype  (TTY)  channels 

•  2-75  Baud  special  intelligence  channels 

•  2-75  Baud  meteorological  channels 

•  1  -  frame  synchronization  channel 

The  fleet  units,  receiving  the  satellite  downlink,  demultiplex  the  single  1200  Baud  signal 
back  into  the  original  sixteen  individual  75  Baud  TTY  channels.  User  communication 
requirements  and  equipment  availability  then  determine  which  of  the  sixteen  channels 
are  actually  decrypted  and  utilized.  It  should  be  noted  that  equipment  availability  is 
usually  the  most  significant  factor  in  determining  channel  utilization.  The  amount  of 
equipment  on  hand  to  decrypt  and  utilize  a  channel  is  dependent  on  the  class  of  ship  and 
it's  mission. 

Of  the  eleven  genser  TTY  channels  available  at  a  Communication  Station  eight 
comprise  the  Fleet  Broadcast.  Normal  configuration  is  six  channels  controlled  directly 
from  the  Fleet  Center  while  the  remaining  two  channels  are  controlled  in  other  spaces. 
Three  of  the  six  channels  are  run  continuously  as  common  or  type  channels  while  the 
remaining  three  are  run  as  either  overload,  rerun,  or  contingency  channels.  [Ref.  1:  pp. 
68-69;  Ref.  2:  pp.39-40] 

Common  channels  generally  contain  messages  for  ail  fleet  units  in  the  Commu¬ 
nication  Area  (COMMAREA);  type  channels  carry  messages  which  are  designated  for 
ships  of  a  particular  warfare  type  (i.e.  amphibious,  destroyer). 

Overload  channels  are  used  as  a  means  of  expanding  system  output  capacity. 
When  an  overload  is  activated,  traffic  which  was  designated  for  a  primary  channel  is 
then  split  between  that  primary  channel  and  the  overload.  This,  in  effect,  doubles  the 
output  capacity  of  the  transmitting  station.  The  activation  of  the  overload  also  requires 
that  the  receiving  fleet  units  allocate  additional  decryption  and  processing  equipment  to 
the  overload. 

Rerun  channels  are  used  for  ensuring  that  units  receive  all  traffic  designated  for 
them.  In  principle,  a  rerun  channel  rebroadcasts  message  traffic  which  was  originally 
broadcast  on  a  primary  channel  some  time  period  before.  For  example,  a  rerun  channel 
will  transmit  message  traffic  one  hour  after  the  initial  message  broadcast  over  a  common 
or  type  channel.  This  enables  the  receiving  units  to  recopy  any  message  which  it  may 
have  missed  on  the  initial  broadcast. 


2.  High  Frequency  Broadcast  (HFB)  System 

High  Frequency  multichannel  communication  serves  as  the  secondary  trans¬ 
mission  medium  for  the  Fleet  Broadcast.  Because  of  the  system's  versatility  and 
survivability,  and  the  growing  vulnerability  of  satellite  communications  systems,  HF 
communications  have  received  increased  emphasis  to  meet  present  and  future  needs. 
The  Chief  of  Naval  Operations  (CNO)  has  mandated  that,  at  a  minimum,  a  complete 
16  channel  HF  broadcast  capability  be  maintained  in  each  of  the  major  communications 
areas  [Ref.  3:  p.  VIII-1J. 

Multichannel  HF  communications  are  similar  in  concept  to  the  satellite  com¬ 
munications  mentioned  above  except  that  the  transmission  medium  is  HF  vice  satellite 
(SHF,  UHF).  Additionally,  the  capability  exists  to  simultaneously  key  on  other  fre¬ 
quency  bands  any  message  being  transmitted  on  HF.  This  process  of  "simo -keying” 
further  improves  the  probability  of  success  on  these  non-satellite  communication  sys¬ 
tems.  The  effects  of  using  HF  as  a  transmission  medium  will  be  expanded  upon  in  later 
chapters.  See  Figure  1  on  page  6. 

C.  ADMINISTRATIVE  TRAFFIC  INTERCEPT 

Message  interception  is  used  as  a  means  of  demand  management;  selected  messages 
are  removed  from  the  system  thereby  lessening  the  total  number  of  messages  actively 
being  processed.  The  purpose  of  an  administrative  traffic  intercept  is  to 

.  .  .  allow  the  Broadcast  Keying  Station  (BKS)  to  remove  from  and/or  suspend 
queueing  to  the  broadcast  (during  extreme  traffic  loading  periods)  ZYB  marked 
messages  [Ref.  4:  p.l]. 

Administrative  traffic  are  messages  which  have  been  deemed  by  the  message  origi¬ 
nator  to  be  non-operational  in  nature.  The  originator  identifies  this  traffic  by  inserting 
ADMIN  in  the  Message  Handling  Instruction  (MHI)  block  of  the  message  form. 

Within  NAVCOMPARS,  after  input  via  an  Optical  Character  Reader  (OCR)  or 
some  other  system  input  device,  the  message  is  marked  with  the  Operating  Signal 
(OPSIG)  ZYB  by  the  resident  software.  The  operating  signal  ZYB  then  serves  to  iden¬ 
tify  a  message  as  administrative  to  the  NAVCOMPARS.  Once  converted  to  ZYB,  the 
administrative  message  is  flagged  for  possible  interception  should  traffic  conditions 
warrant. 

Additional  processing  will  assign  a  message,  whether  operational  or  administrative, 
a  Routing  Indicator  (RI)  based  on  the  addressee  (final  destination).  The  RI  assigned 


5 


will  then  be  matched  with  a  Logical  Reference  Number  (LRN)  which  designates  the 
output  path  required  for  message  delivery. 

At  this  point  in  processing,  a  specific  message  is  either  in  queue  awaiting  trans¬ 
mission,  or  enroute  to  a  LRN's  queue.  As  mentioned  above,  it  is  possible  for  broadcast 
queues  to  become  congested  due  to  high  traffic  loading:  in  this  situation  the  broadcast 
LRN  becomes  a  likely  candidate  for  some  sort  of  demand  management  action  (i.e.  an 
intercept). 

If  the  system  manager  invokes  an  administrative  intercept  all  messages  llaggcd  with 
ZYB  OI’SlGs  will  be  intercepted  cither  from  the  LRN  queue  or  enroute  to  the  queue. 
These  intercepted  messages  are  then  sent  to  the  Screening  Board  printer  LRN  for 
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printing. 3  Messages  sent  to  the  Screening  Board  are  then  individually  examined  by 
members  of  the  board  to  determine  further  action.  Further  actions  may  include:  [Ref. 
5:  p.35] 

•  delivery  by  other  means  (i.e.  courier,  mail) 

•  immediate  reentry  in  NAVCOMPARS  for  broadcast 

•  holding  for  reentry  when  queue  conditions  warrant 

A  more  detailed  explanation  of  ZYB  intercept  modes  and  message  reentry  options 
is  provided  in  the  following  sections. 

D.  ADMINISTRATIVE  TRAFFIC  INTERCEPT  MODES 

Removal  of  administrative  traffic  from  NAVCOMPARS  is  performed  by  two  dif¬ 
ferent  methods;  an  alternate  routing  (altroute)  or  a  redirect. 

An  altroute  command  is  used  to  remove  messages  which  are  already  queued  on  a 
LRN  awaiting  transmission.  A  redirect  command  is  used  to  divert  messages  from  a 
LRN  which  may  be  backlogged  or  non-operational  due  to  equipment  malfunctions  or 
outages.  [Ref.  5:  p.28,p.35] 

1.  ZYB  Altroute  Mode  -  AM  Command 

The  AM  altroute  is  designed  to  remove  existing  administrative  traffic  from  a 
specified  LRN  queue.  In  NAVCOMPARS  Release  11.0  the  specified  LRN  must  be  a 
broadcast  type;  in  the  upcoming  Release  12.0  the  LRN  can  be  broadcast,  full  period, 
dedicated  or  CUDIXS.4  See  Figure  2  on  page  8.  [Ref.  4:  p.3;  Ref.  6] 

The  AM  command  is  applicable  for  Immediate  precedence  messages  and  below. 
For  example,  an  altroute  of  Immediate  administrative  traffic  will  also  result  in  the 
altrouting  of  Priority  and  Routine  traffic. 

Upon  completion  of  the  LRN  purge  the  AM  command  will  automatically  de¬ 
lete. 


3  The  Screening  Board  LRN  is  also  the  final  destination  for  a  Screening  Board  altroute  and 
redirect  function.  The  Screening  Board  functions  are  similar  to  an  Administrative  Screen  except 
that  all  messages,  whether  operational  or  administrative  in  nature,  are  affected. 

4  CUDIXS,  the  Common  User  Digital  Information  Exchange  System,  is  a  communications 
link  between  a  shore  communication  element  and  fleet  units,  using  UHF  satellites.  CUDIXS  can 
serve  up  to  sixty  properly  equipped  units  using  a  polling  scheme  for  transmission  and  reception 
order. 
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Figure  2.  AM  Command  *  NAVCOMPARS  Release  11.0  and  12.0 


2.  ZYB  Redirect  Mode  -  ADM  Command 


The  ADM  command  is  used  by  the  system  operator  to  prevent  delivery'  of  ZYB 
designated  messages  to  a  specified  LRN.  Initiation  of  the  command  will  direct  qualify¬ 
ing  messages  from  the  original  LRN  to  the  Screening  Board  printer.?  See  Figure  3  on 
page  9.  The  precedence  rules  mentioned  above  for  the  AM  command  are  also  applicable 


for  the  ADM  command. 


L'nlike  the  AM  command  the  ADM  command  must  be  manually  terminated  by 
the  system  operator.  (Ref.  4:  p.2] 


5  The  Screening  Board  printer  is  the  only  allowed  destination  LRN  currently  used  with 
NAVCOMPARS  Release  11.0.  Release  12.0  will  incorporate  additional  destination  LRN’s  when 
installed. 
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Figure  3.  ADM  Command  -  NAVCOMPARS  Release  11.0  and  12.0 


3.  Combination  AM/ADM  Command  Usage 

In  addition  to  being  used  separately  the  AM  and  ADM  commands  can  be  used 
simultaneously  on  the  same  source  LRN.  Operating  in  this  mode  the  ADM  command 
will  direct  newly  arriving  traffic  to  the  Screening  Board  LRN  while  the  AM  command 
clears  the  specified  source  LRN  queue  of  existing  administrative  messages.  As  men¬ 
tioned  above,  the  AM  command  will  automatically  delete  when  the  source  LRN  is 
purged  of  qualifying  messages.  The  ADM  command  will  require  operator  action  for 


command  removal. 


HBBngtw  girerowmiai 


E.  MESSAGE  REENTRY  MODES 

Messages  that  have  been  altrouted  or  redirected  to  the  Screening  Board  printer  as 
a  result  of  an  administrative  intercept  must  be  screened  to  determine  the  next  step  in 
processing.  At  this  point  the  individual  message  can  either  be  delivered  by  other  means 
or  reentered  into  the  system  immediately  or  later,  depending  on  queue  conditions. 

Reentry  of  intercepted  messages  into  the  system  can  be  achieved  either  through  the 
intervention  of  a  system  operator  at  a  Command  Video  Data  Terminal  (VDT),  the  cre¬ 
ation  of  a  reentry  tape,  or  the  use  of  reentry  altroutes.  [Ref.  7:  pp.71-72;  Ref.  4:  p.4] 

1.  VDT  Initiated  Message  Reentry 

Within  NAVCOMPARS,  the  Message  Processing  Subsystem  (MPS)  performs 
message  analysis  and  VDT  interface.  The  software  module  used  for  VDT  interface  is 
MPSVC.  By  using  MPSVC  and  a  VDT,  it  is  possible  to  reenter  intercepted  adminis¬ 
trative  messages  using  SVC  commands.  Two  SVC  commands  are  used  for  reentering 
intercepted  messages:  SBR  and  SBO  [Ref.  8:  p.71]. 

The  use  of  the  SBR  command  will  requeue  the  message  to  the  original  LRN  for 
transmission.  In  the  event  that  another  administrative  altroute  is  performed  these  re¬ 
queued  messages  will  again  be  intercepted. 

The  SBO  command  is  similar  to  the  SBR  command  except  that  it  will  override 
any  administrative  altroute  which  takes  place  while  the  requeued  message  awaits  trans¬ 
mission.  [Ref.  9:  p.164] 

2.  Message  Reentry  Tape 

An  alternate  method  of  reentry  is  accomplished  through  the  creation  of  a  re¬ 
entry  tape  using  an  off-line  program.  This  program  will  extract  identified  administrative 
messages  from  the  journal  tape,  reformat  the  messages  appropriately,  and  then  write 
them  to  a  reentry  tape.  The  system  operator  can  then  input  the  messages  back  into 
NAVCOMPARS  using  the  reentry  tape. 

3.  Reentry  Altroutes 

Intercepted  messages  can  also  be  reentered  from  the  Screening  Board  using  re¬ 
entry  altroutes.  The  reentry  altroutes  include: 

•  channel  reentry 

•  short  title  reentry 

•  routing  indicator  reentry 

•  count  reentry 


Reentry  altroutes  return  intercepted  messages  to  the  system  if  the  specified 
precedence  range  and  subject  parameter  requirements  are  met.  Channel  reentry  returns 
to  the  source  LRN  messages  which  meet  the  precedence  and  destination  channel  re¬ 
quirements.  Short  title  and  routing  indicator  reentry  commands  are  similar  to  the 
channel  reentry,  with  the  message  short  title  and  routing  indicator  being  the  second 
specified  parameter.  Count  reentry  differs  slightly;  the  parameters  specified  by  this 
command  are  the  precedence  range  and  number  of  messages  to  be  reentered.  Any  mes¬ 
sage  meeting  the  criteria  of  the  selected  reentry  altroute  will  be  requeued  for  trans¬ 
mission  by  the  system.  [Ref.  7:  pp.45-47j 
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III.  ADMINISTRATIVE  MESSAGE  INTERCEPT  IMPLEMENTATION 

STRATEGIES 


A.  INTRODUCTION 

The  use  of  an  administrative  message  intercept  to  alleviate  a  broadcast  queue 
buildup  is  only  one  of  many  traffic  management  options  available  to  the 
NAVCOMPARS  manager.  The  decision  to  invoke  an  intercept  command  should  take 
into  account  many  factors  and  considerations.  Among  these  factors  are  the  current 
operational  situation  (external  factors),  NAVCOMPARS  system  status  (internal  fac¬ 
tors),  and  the  transmission  medium  in  use.  In  this  chapter  the  following  factors  will  be 
addressed: 

1.  External  Factors 

2.  Internal  Factors 

3.  Transmission  Considerations 

4.  Proposed  Strategies 

B.  EXTERNAL  FACTORS 

When  forming  decisions  on  traffic  management  options  the  systems  manager  must 
take  into  account  factors  external  to  the  NAVCOMPARS.  These  factors  may  have 
some  bearing  on  what  option  the  manager  chooses  to  pursue.  Factors  to  consider  in¬ 
clude: 

1.  Time 

2.  Types  of  Users 

3.  Exercise  Conditions 

4.  World  Events 

1.  Time 

Time  factors  to  be  considered  include  the  time  of  day  and  the  day  of  the  week. 
The  message  releasing  rates  of  users  within  a  NAVCAMS's  COMMAREA  may  show 
some  sort  of  pattern  over  a  period  of  twenty-four  hours.  For  example,  given  that  most 
messages  are  written  during  a  normal  working  day,  it  may  develop  that  these  messages 
will  enter  NAVCOMPARS  late  afternoon  or  early  evening  local  time,  creating  a  higher 
traffic  arrival  rate.  This  proposed  scenario  combined  with  an  already  congested 
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N'AVCOMPARS  suggests  imminent  difficulties  for  system  managers  and  operators. 
Trends  such  as  these  requires  an  operator's  attention. 

The  day  of  the  week  has  also  shown  cyclic  traffic  patterns.  Comparing  traffic 
conditions  shows  that  Wednesday  through  Friday  are  generally  the  heaviest  load  days, 
concurrent  with  the  end  of  the  workweek.  Considering  these  cycles  may  aid  a  decision 
maker  in  forecasting  a  possible  drop  or  increase  in  traffic  arrival  rates.  [Ref.  5:  p.37] 

2.  Types  of  Users 

Each  Naval  Communication  Area  Master  Station  (NAVCAMS)  is  responsible 
for  communications  within  a  geographical  area  [Ref.  3:  p.IV-1].  A  systems  manager 
should  know  both  the  number  and  type  of  users  within  its  Communication  Area 
(COMMAREA);  using  this  information  enables  the  manager  to  better  judge  the  poten¬ 
tial  for  traffic  loading.  For  example,  the  arrival  of  multiple  Carrier  Battle  Groups 
(CVBG)  into  a  COMMAREA  presents  many  factors  to  be  considered.  The  increase  in 
the  total  number  of  fleet  units  will  undoubtedly  increase  message  traffic  arrival.  An  alert 
NAVCAMS  should  have  overload  circuits  ready  or  arranged  for  to  handle  expected  in¬ 
creases.  Additionally,  the  commands  controlling  these  units  will  generate  additional  high 
precedence  traffic.  Again,  this  may  warrant  additional  overloads.  [Ref.  5:  p.37] 

3.  Exercise  Conditions 

The  operational  schedule  of  users  within  a  COMMAREA  should  also  be  con¬ 
sidered.  The  conducting  of  exercises  will  increase  message  traffic  arrival  rates  as  coor¬ 
dination  takes  place.  This  increase  will  continue  during  the  actual  exercise  and  will 
probably  not  lessen  until  the  exercise  is  well  over. 

4.  World  Events 

World  events  can  usually  be  expected  to  affect  message  traffic  loading  also.  The 
outbreak  of  conflict  in  a  NAVCAMS's  COMMAREA,  whether  directly  or  indirectly 
involving  U.S.  forces,  will  increase  communication  activity  as  reports  and  observations 
are  sent  to  command  and  control  centers.  Few  such  outbreaks  occur  instantaneously; 
the  system  manager  should  be  aware  of  potential  areas  and  the  possible  effects  on  traffic. 

C.  INTERNAL  FACTORS 

In  addition  to  external  factors  a  NAVCOMPARS  operator  must  closely  monitor  the 
equipment  and  assets  available  to  him  or  her.  Keeping  an  overall  picture  of  the  system's 
parameters  should  enable  the  watch  teams  to  forecast  any  inhouse  problems  short  of 
catastrophic  equipment  failure. 


Inherent  in  NAVCOMPARS  are  system  status  displays  which  are  printable  in  hard 
copy  form.  These  reports  are: 

•  Input  Queue  Summary  Report 

•  Output  Queue  Summary  Report 

•  Data  Pattern  Directory  Report 

•  CUDIXS  Output  Summary  Report 

•  Intercept  File  Queue  Report 

•  System  Queue  Summary  Report 

Timely  usage  of  the  above  reports6  should  enable  the  operator  to  identify  trends,  po¬ 
tential  backlog  situations,  or  any  unusual  problems. 

In  addition  to  the  hard  copy  reports,  queue  status  can  also  be  obtained  from: 

•  Computer  Operator  console  typeouts,  both  unsolicited  and  initiated 

•  VDT  Display 

•  Teletype  Logs 

Console  typeouts  appear  as  the  result  of  computer  detected  conditions;  typeouts  are 
also  the  result  of  operator  initiated  requests.  Example  typeouts  include  reached  queue 
limits,  queue  overflow,  input/output  errors,  or  imminent  storage  wraparound.  Com¬ 
mand  VDT  status  displays  can  also  achieve  similar  results  as  the  hard  copy  reports 
mentioned  above.  Teletype  logs  are  LRN-oriented;  typeouts  of  this  type  indicate  com¬ 
puter  detected  conditions  at  specific  channel  logs. 

Additional  system  status  indicators  are  the  Output  Queue  Profile  Reports: 
NCQPROS  and  NCQPROT.  These  background  programs  available  on  90/60 
computer-equipped  systems  provide  profile  data  for  each  message  on  a  selected  LRN 
output  queue.  NCQPROS  provides  printed  output  data  in  ascending  order  by  originator 
short  title.  NCQPROT  provides  profile  data  on  a  queue  by  message.  [Ref.  5:  pp.  13-25} 

D.  TRANSMISSION  CONSIDERATIONS 

In  addition  to  NAVCOMPARS'  internal  system  status  reports  and  the  external 
considerations,  the  system  manager  must  consider  the  transmission  medium  being  used. 
As  stated  in  Chapter  two,  the  Fleet  Broadcast  is  primarily  carried  via  satellite  on  one  of 
the  Fleet  Satellite  Broadcast  systems,  or  it  is  carried  using  High  Frequency  radio 

6  For  a  more  detailed  explanation  of  the  above  listed  reports  see  NAVTASC  Document  No. 
15X7001  OM-02C,  NAVCOMPARS  Computer  Operation  Manual. 
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communications.  When  operating  in  either  transmission  mode,  the  operator  must 
understand  the  nuances  of  each  of  the  individual  systems. 

The  primary  difference  between  HF  and  satellite  communication  is  the  frequencies 
used.  Satellite  communications  typically  operate  in  Ultra  High  Frequency  (UHF)  (300 
Mhz-3Ghz),  Super  High  Frequency  (SHF)  (3Ghz-30Ghz),  or  in  a  combination  of  UHF 
and  SHF  (i.e.  SHF  uplink,  UHF  downlink).  The  particular  satellite  constellation  in  use 
by  the  NAVCAMS  will  determine  the  applicable  frequency  range.  HF  systems  operate 
in  the  3  Mhz  -  30  Mhz  frequency  range.  [Ref.  1:  p.56] 

The  chief  disadvantage  of  HF  communications  is  the  susceptibility  of  radio  wave  in 
this  range  to  attenuation  and  atmospheric  disturbances.  Maximum  Useable  Frequency 
(MUF)  and  Lowest  Useable  Frequency  (LUF)  are  concepts  used  in  understanding 
ionization  effects  on  HF  propagation.  The  time  of  day,  placement  of  the  moon,  season 
of  the  year,  latitude  of  the  transmission,  presence  of  sunspots,  or  meteor  showers,  indi¬ 
vidually  or  in  combination,  all  affect  the  probability  of  successful  HF  communication. 
The  above  factors  are  all  contributors  to  atmospheric  ionization;  this  ionization  can  lead 
to  HF  attenuation  by  absorption.  To  ensure  satisfactory  HF  communications  both  the 
sender  and  the  receiver  of  an  HF  signal  will  have  to  display  a  fair  amount  of  frequency 
agility  to  stay  below  MUF  and  above  LUF.  [Ref.  10:  pp.  11-1  -  11-llj 

Because  of  HF  attenuation  problems,  prudent  practice  may  require  the  activation 
of  additional  rerun  channels  on  the  Fleet  Broadcast.  These  channels,  run  in  combination 
with  common  or  type  channels,  would  increase  the  probability  of  receiving  all  messages 
on  the  fleet  unit  should  a  message  or  messages  be  unreadable  due  to  atmospheric  con¬ 
ditions. 

E.  PROPOSED  STRATEGIES 

As  mentioned  in  Chapter  One,  Commander,  Naval  Telecommunications  Systems 
Command  (CNTC)  promulgated  proposed  thresholds  for  the  implementation  of  an  ad¬ 
ministrative  message  intercept.  These  thresholds  were  to  be  recommended  to  the  Fleet 
Commander  in  Chiefs  (FLTCINCs)  [Ref.  11).  See  Table  1  on  page  16  for  a  listing  of 
the  proposed  thresholds. 

COMNAVTELCOM  also  solicited  comments  and/or  recommendations  concerning 
the  proposed  thresholds.  In  this  section  the  responses  from  each  of  the  message  ad¬ 
dressees  will  be  presented. 
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Table  1.  COMNAVTELCOM  PROPOSED  IMPLEMENTATION  STRATE¬ 
GIES 


QUEUE  BACKLOG 

ACTION 

70 

Analyze  to  determine  if  specific  units  can  be  brought 
up  on  special  CUDIXS  to  clear  single  addee  messages. 

175 

Implement  admin  message  intercept  for  affected 
broadcast  channels. 

50 

Commence  reentering  diverted  messages. 

1.  NAVCOMMSTA  Stockton  CA 

The  comments  from  NAVCOMMSTA  Stockton  were  generally  negative  con¬ 
cerning  the  proposed  threshold  limits.  The  primary  comment  was  that  a  standard  traffic 
threshold  would  restrict  effective  broadcast  management  by  not  allowing  the  operators 
onhand  to  exercise  real-time  decision  making.  The  need  to  consider  operational  tempo 
and  requirements  was  also  emphasized.  (Ref.  12] 

2.  NAVCAMS  EASTERN  PACIFIC  Honolulu  HI 

The  response  from  NAVCAMS  EASTPAC  generally  paralleled 
NAVCOMMSTA  Stockton's  response.  The  response  again  emphasized  that  the 
uniqueness  of  each  situation,  in  terms  of  operational  requirements  and  the  operating 
environment,  required  flexibility  which  would  be  reduced  with  the  promulgation  of 
standard  thresholds. 

The  message  from  NAVCAMS  EASTPAC  provided  two  alternatives,  one  for  a 
satellite  environment  and  one  for  operating  in  a  HF  environment.  The  threshold  limits 
are  provided  in  Table  2  on  page  17  and  Table  3  on  page  17. 

The  reasoning  behind  the  different  thresholds  is  that  operating  in  HF  differs 
from  operating  by  satellite.  The  quality  of  a  HF  signal,  as  mentioned  in  previous 
sections,  is  heavily  dependent  on  the  environment  and  usually  requires  the  activation  of 
rerun  channels  to  ensure  greater  probability  of  message  reception.  By  activating  an  ad¬ 
ministrative  intercept  first,  the  requirement  for  fleet  units  to  secure  rerun  channels  in 
order  to  receive  newly  activated  overload  channels  is  delayed  as  long  as  possible.  [Ref. 
13] 

3.  NAVCAMS  ATLANTIC  Norfolk  VA 

NAVCAMS  LANT's  response  to  the  CNTC  request  was  also  negative  towards 
the  use  of  administrative  intercepts.  NAVCAMS  LANT  suggests  the  following  system, 
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Table  2.  HIGH  FREQUENCY  ENVIRONMENT  THRESHOLDS  -  NAVCAMS 
EASTPAC 


QUEUE  BACKLOG 

ACTION 

75 

Analyze  Queue  profiles  to  determine  specific  reasons 
for  backlog.  Try  to  reduce  backlog  with  various  man¬ 
agement  options,  less  overload  activation  or  admin  in¬ 
tercept. 

100 

Invoke  administrative  intercept  to  the  precedence  level 
necessary  to  promote  timely  delivery  of  operational 
traffic. 

175 

Activate  Broadcast  overload  channels ). 

20 

Reenter  intercepted  messages.  When  all  the  messages 
have  been  reentered,  revoke  the  intercept(s). 

Table  3.  SATELLITE  1 
EASTPAC 

ENVIRONMENT  THRESHOLDS  -  NAVCAMS 

QUEUE  BACKLOG 

ACTION 

75 

Analyze  queue  profiles  to  determine  specific  reasons  for 
backlog.  Try  to  reduce  backlog  with  various  manage¬ 
ment  options,  less  overload  activation  or  admin  inter¬ 
cept. 

175 

Invoke  administrative  intercept  to  the  precedence  level 
necessary  to  promote  timely  delivery  of  operational 
traffic. 

100 

Activate  Broadcast  overload  channel(s). 

20 

Reenter  intercepted  messages.  When  all  the  messages 
have  been  reentered,  revoke  the  intercept(s). 

when  combined  with  active  evaluation  of  the  broadcast  backlog  and  real  world  opera¬ 
tional  conditions,  to  be  more  effective  than  the  CNTC  proposed  thresholds: 

•  Prompt  activation  of  overload  channels,  if  not  in  HF  environment. 


•  Review  queue  profiles  on  various  channels  and  reduce  broadcast  queue  by  sending 
single  addressee  messages  to  special  CUDIXS  termination.? 


7  Using  Queue  Profiles  allows  the  NAVCOMPARS  manager  to  review  messages  held  in 
queue  for  an  output  channel.  By  inspecting  the  profile  the  manager  may  identify  a  fleet  unit  which 
has  a  high  number  of  messages  dated  for  delivery.  With  this  information  the  manager  can  altroute 
those  messages  through  alternate  delivery  means  (i.e.  CUDIXS). 


•  Activate  RCS  overflow  for  high  speed  input  lines.  This  removes  lower  precedence 
traffic  onto  an  overflow  tape  for  later  reentry  using  controlled  automatic  methods. 

•  Final  alternative,  activate  TPS  intercept  for  routine  messages. 

NAVCAMS  LANT  also  addresses  the  manpower  efficiency  of  administrative 
intercepts  as  well  as  the  need  for  a  magnetic  tape  store  and  recall  feature.  These  issues 
will  be  addressed  in  following  sections.  [Ref.  14] 

4.  NAVCAMS  WESTERN  PACIFIC  Guam 

The  response  from  NAVCAMS  WESTPAC  was  similar  to  that  of  NAVCAMS 
EASTPAC.  Similar  points  concerning  the  lack  of  flexibility  from  a  standard  threshold 
and  the  need  for  real-time  comprehensive  situational  analysis  were  raised. 

NAVCAMS  WESTPAC  also  highlighted  the  requirement  for  a  standard  which 
addressed  HF  and  satellite  communications  individually.  The  reasoning  again  centered 
on  the  fact  that  the  success  of  HF  communications  is  heavily  dependent  on  the  current 
environmental  conditions;  because  of  this  dependency,  fleet  units  must  configure  to  re¬ 
ceive  rerun  channels,  in  addition  to  their  common  and  type  channels,  to  ensure  highest 
probability  of  receiving  all  messages.  See  Table  4  on  page  19  and  Table  5  on  page  19 
for  proposed  thresholds.  [Ref.  15] 

5.  NAVCAMS  MEDITERRANEAN  Naples  Italy 

NAVCAMS  MED  generally  concurred  with  the  responses  mentioned  above. 
Again,  the  need  to  fully  utilize  the  talents  and  experience  of  on-scene  personnel  was 
emphasized.  A  comment  was  also  made  that  the  imposition  of  standard  thresholds 
would  reduce  flexibility  and  stifle  initiative  of  the  Broadcast  Control  Authority  (BCA). 

There  were  no  proposed  threshold  limits  but  it  was  mentioned  that  NAVCAMS 
MED  procedures  called  for  activating  overload  channels  when  broadcast  queues  reached 
60  to  70  messages.  There  was  no  mention  of  differences  between  operating  in  a  HF  or 
satellite  environment.  [Ref.  16] 

6.  Naval  Telecommunications  Systems  Integration  Center 

The  Naval  Telecommunications  Systems  Integration  Center  (NAVTELSYSIC) 
was  also  solicited  for  comments  and/or  recommendations  concerning  the  proposed 
thresholds;  NAVTELSYSIC  currently  serves  as  the  NAVY's  telecommunication  certif¬ 
ication  facility  [Ref.  3:  p. II 1-2]. 

The  comments  submitted  by  NAVTELSYSIC  stated  that  the  thresholds  pro¬ 
posed  conflicted  with  the  numbers  listed  in  REF.  3  with  respect  to  the  activation  of 


Table  4.  HIGH  FREQUENCY  ENVIRONMENT  THRESHOLDS  -  NAVCAMS 
WESTPAC 


QUEUE  BACKLOG 

ACTION 

70 

Analyze.  Implement  special  management  actions  (ac¬ 
tivate  HF  RFCS  Termination). 

100 

Implement  admin  intercepts. 

150 

Commence  overload  activation  process  if  conditions 
allow. 

50 

Reenter  intercepted  admin  messages. 

Table  5.  SATELLITE 
WESTPAC 

ENVIRONMENT  THRESHOLDS  -  NAVCAMS 

70 

Analyze.  Implement  special  management  actions 
(Special  CUDIXS  termination). 

150 

Implement  admin  intercepts. 

100 

Commence  overload  activation  process. 

50 

Reenter  intercepted  admin  messages 

overload  channels.  The  Current  FOTP  instruction  calls  for  the  activation  of  overloads 
at  a  queue  backlog  of  150  messages. 

NAVTELSYSYIC  also  recommended  that  the  individual  NAVCAMS  be  al¬ 
lowed  to  establish  their  own  implementation  thresholds  for  administrative  intercepts. 
[Ref.  17] 

7.  Response  Summary 

The  responses  generated  by  CNTC's  request  for  comments  and/or  recommen¬ 
dations  had  many  common  points.  Areas  in  common  dealt  with  the  effect  of  standard 
guidance  on  organizational  relationships  and  decision  making,  the  need  for  more  envi¬ 
ronment  oriented  considerations,  and  the  perceived  design  deficiencies  of  the  adminis¬ 
trative  message  intercept.  Another  common  thread  that  ran  through  the  solicited 
responses  was  that  queue  levels  through  NAVCO.MPARS  are  used  as  the  most  basic 
indicator  of  the  current  system  status.  Although  the  actual  numbers  varied,  the  general 
rule  to  success  was  to  keep  a  queue  level  below  a  selected  level. 

Many  comments  were  made  concerning  the  effect  of  standard  thresholds  on  the 
organizational  relationships  between  the  FLTCINCs  and  the  individual  NAVCAMS. 


The  FLTCINCs,  as  operational  commanders,  exercise  authoritative  control  over  the 
communication  assets  within  their  geographical  area  of  control  [Ref.  3:  p.V-2].  The  is¬ 
suance  of  CNTC  guidance  is  perceived  as  an  erosion  of  this  operational  authority. 

Decision  matting  issues  were  also  raised;  specifically,  that  the  guidance  failed  to 
take  into  account  the  dynamic  nature  of  the  operating  environment.  Additional  com¬ 
ments  w'ere  that  the  experience  and  talents  of  on-scene  personnel  were  not  fully  utilized 
when  operating  under  such  guidance.  It  was  felt  that  operators  on  station  could  more 
adequately  address  an  increasing  queue  problem  by  working  with  all  resources  available 
at  the  NAVCAMs,  rather  then  by  invoking  a  static  set  of  procedures. 

The  need  for  HF  and  satellite  environment  considerations  was  also  highlighted. 
The  guidance  failed  to  consider  the  differences  when  operating  with  either  HF  or  satel¬ 
lite. 

The  effectiveness  and  efficiency  of  administrative  message  intercepts  were  also 
questioned.  The  comment  was  made  that  the  intercept  was  manpower  intensive  due  to 
the  reentry  procedures;  this  is  critical  with  the  current  and  future  state  of  Naval  man¬ 
ning.  The  need  for  a  magnetic  tape  store  and  recall  feature  was  mentioned;  this  would 
enable  the  operators  to  reenter  intercepted  messages  by  automatic  means  when  queue 
levels  permit. 

As  mentioned  above,  queue  levels  are  seen  by  both  CNTC  and  the 
NAVCAMSs,  as  serving  as  a  solid  measure  of  system  status.  Since  this  appears  to  be 
the  case  throughout  the  Naval  Telecommunications  System  (NTS),  this  research  will 
also  utilize  queue  levels  as  a  status  indicator  on  the  simulation  model. 


IV.  COMPUTER  SIMULATION  METHODOLOGY 


A.  INTRODUCTION 

In  this  chapter,  an  overview  of  simulation  will  be  presented,  followed  by  an  intro¬ 
duction  to  General  Purpose  Simulation  System  (GPSS)  V.  The  final  sections  will  pertain 
to  the  actual  model  of  simulation  used  for  this  research. 

B.  AN  OVERVIEW  TO  SIMULATION 

It  often  turns  out  that  it  is  not  possible  to  develop  analytical  models  for  queueing 
systems.  This  can  be  due  to  the  characteristics  of  the  input  or  service  mechanisms, 
the  complexity  of  system  design,  the  nature  of  the  queue  discipline,  or  combinations 
of  the  above  [Ref.  18:  p.455]. 

The  above  quotation  by  Gross  and  Harris  lists  the  possible  reasons  or  combinations 
of  reasons  why  simulation  might  serve -as  an  adequate  representation  of  an  actual 
queueing  system.  Emphasis  is  placed  on  adequate.  However,  simulation  is  experiment¬ 
ing  through  the  use  of  changing  parameters;  because  of  this,  simulation  can  be  subject 
to  the  same  limitations  of  any  experimentation.  Limitations  may  include  the  validity  of 
any  inferences  or  assumptions  made;  this  idea  must  be  kept  in  mind  throughout  the 
simulation  process. 

The  execution  of  a  simulation  model  can  be  divided  into  three  phases: 

•  Data  Generation 

•  Bookkeeping 

•  Output  Analysis 

Data  generation  is  the  creation  of  customers,  the  subject  of  the  transaction.  The  creation 
of  customers  can  be  multiphased;  the  first  phase  is  the  actual  generation  of  the  subject 
customer.  The  second  phase  is  the  assignment  of  attributes  to  the  customer;  this  is  con¬ 
ditional  on  the  particular  simulation  model  in  use  since  a  customer  may  have  many  at¬ 
tributes  or  none  at  all. 

Bookkeeping  is  the  gathering  of  measurements  as  the  simulation  model  is  run. 
Measurements  may  include  the  arrival  and  departure  of  each  customer,  the  times  in¬ 
volved  in  each  significant  part  of  the  simulation,  and  the  number  of  customers  utilizing 
these  significant  sections  of  the  simulation. 


The  third  and  final  phase  is  output  analysis.  Using  the  data  provided  by  the  book¬ 
keeping  phase,  measurements  are  generated  for  analysis.  Typical  measurements  and  re¬ 
sults  may  include  average  queue  size,  average  time  in  queue,  idle  time,  or  average  waiting 
time.  [Ref.  18:  pp.456-469] 

Figure  4  on  page  23  provides  a  diagram  showing  the  three  phases  of  simulation. 
Note  the  recursive  feature  between  the  Data  Generation  phase  and  the  Bookkeeping 
phase;  this  represents  the  repetitive  runs  with  compilation  of  data  for  the  Output  Anal¬ 
ysis  phase. 

C.  GENERAL  PURPOSE  SIMULATION  SYSTEM  (GPSS)  V 

GPSS  is  a  block  diagrammatic  simulation  language  which  uses  command  operations 
to  define  a  system  structure  [Ref.  18:  p.471j.  The  fundamental  element  in  GPSS  is  the 
entity;  entities  are  designed  to  perform  a  variety  of  functions  relative  to  the  type  of  entity 
that  it  is.  The  most  frequently  used  entities  are  [Ref.  19:  p.7]: 

•  transactions 

•  blocks 

•  facilities 

•  storage 

•  queue 

•  logical  switches 

•  boolean  variables 

Transactions  are  the  principal  items  of  movement  within  a  simulated  model;  they 
can  be  created  or  destroyed  dependent  upon  the  model  requirements.  Transactions  can 
also  be  assigned  up  to  1020  attributes;  through  the  use  of  these  attributes,  it  is  possible 
to  make  each  individual  transaction  somewhat  unique. 

Blocks  are  used  to  perform  command  operations  which  were  described  when  a  sys¬ 
tem  was  analyzed.  Blocks  may  perform  four  basic  events: 

•  creation  and  destruction  of  a  transaction 

•  alteration  of  an  entity's  numerical  attribute 

•  transaction  delay  consistent  with  simulated  action 

•  model  flow  alteration 

Facilities  are  used  to  represent  equipment;  a  facility  may  be  used  to  simulate  the 
process  of  a  cashier  operating  a  grocery  check-out  stand  or  any  process  in  a  model  which 


Figure  4.  Three  Phases  of  System  Simulation 


acts  as  a  server.  It  should  be  noted  that  only  one  transaction  may  occupy  a  facility  at 
a  given  time. 

Parallel  processing  equipment  is  represented  using  storages.  Storages  can  be  used 
to  represent  the  maximum  capacity  of  a  room  or  the  maximum  storage  available  on  a 
magnetic  tape  unit. 

Since  facilities  emulate  single  servers  and  storages  have  some  set  maximum  capacity, 
transactions  may  be  delayed  awaiting  a  facility's  process  or  a  storage's  availability.  In 
this  event,  a  transaction  is  held  in  queue;  these  transactions  will  be  held  until  the  facility 
or  storage  become  available. 

Logical  switches  are  used  to  block  or  divert  traffic  dependent  on  the  value  of  the 
switch.  Transactions  can  also  be  utilized  to  set,  reset,  or  invert  a  switch. 

Boolean  variables  can  be  used  to  make  decisions  based  on  numerous  values;  for  ex¬ 
ample.  any  specific  attribute  of  a  transaction  can  be  used  as  a  basis  for  a  decision  using 
some  sort  of  operator.  Example  operators  include  conditional,  boolean,  and  logical  at¬ 
tributes.  (Ref.  19:  pp.5-7] 

To  aid  in  the  generation  of  output  most  of  the  above  mentioned  entities  create  and 
maintain  their  own  statistics.  The  queue  entity,  for  example,  gathers  queue  length,  av¬ 
erage  time  in  queue,  total  number  of  entries,  average  time  per  transaction  spent  in 
queue,  and  more.  For  a  more  detailed  explanation  of  each  entity  and  it's  statistics,  the 
reader  must  refer  to  Ref.  19  or  Ref.  20. 

See  Figure  5  on  page  24  for  an  illustration  of  a  GPSS  block  diagram  for  a  single 
server  queue  model.  In  this  single  server  simulation  a  transaction  is  created  in  the 


Figure  5.  Generic  GPSS  Simulation  Model  (Single  Server  Queue  Model) 


generate  entity.  Following  generation  the  transaction  enters  a  queue  block  with 
subsequent  entry  into  a  seize  block.  The  queue  block  is  entered  to  simulate  a  line  of 
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transactions  awaiting  the  use  of  the  following  facility;  the  use  of  the  queue  also  generates 
valuable  statistics,  as  mentioned  above.  The  seize  block  engages  a  specified  facility  to 
simulate  some  action  taking  place;  once  the  facility  is  seized  the  transaction  is  allowed 
to  leave  the  queue  via  the  depart  block.  To  generate  a  service  time  for  the  transaction 
GPSS  uses  the  advance  block;  the  advance  block  generates  a  delay  time  comparable  to  a 
service  time.  Upon  completion  of  the  delay  time  the  transaction  is  released  for  further 
processing.  The  final  block  is  the  terminate  block;  it  is  in  this  block  that  the  transaction 
is  destroyed. 

D.  SIMULATION  MODEL  DESIGN 

1.  Simulation  Model  Foundation 

In  Glenn's  research  on  administrative  message  schemes  he  states  the  following 
regarding  the  Fleet  Broadcast: 

.  . .  Broadcast  can  be  looked  upon  as  15  parallel,  nonidentical  M/M/1  transmission 
facilities.  Each  channel  has  unique  message  arrival  and  service  rates  and  is  assumed 
to  be  a  single  service  supplying  its  subscribers  with  the  message  traffic  it  transmits 
[Ref.  21:  p.43]. 

Glenn  later  states, 

.  .  .  final  and  most  detailed  model  definition  can  be  viewed  as  approximately  seven 
parallel  nonidentical  facilities  which  would  correspond  with  the  number  of  first  run 
channels,  regular  and  overload,  that  are  used  [Ref.  21:  p.43). 

For  the  purpose  of  simulation  it  will  be  assumed  that  Glenn's  proposals  are 
valid.  With  this  in  mind,  the  idea  that  each  output  channel  is  a  single  server  will  serve 
as  the  basis  for  this  research's  model. 

See  Figure  6  on  page  26  for  an  illustration  of  the  system  model. 

2.  Simulation  Model  Limitations 

As  explained  in  Chapter  Two,  the  activation  of  an  administrative  intercept  re¬ 
sults  in  either  the  altrouting  of  messages  in  queue  on  the  output  channel,  or  the  redi¬ 
recting  of  newly  arriving  messages  from  the  selected  channel.  The  action  performed  is 
dependent  on  the  mode  chosen  by  the  system  manager.  In  modeling  the  AM  command 
feature  the  simulation  package  would  be  required  to  screen  messages  already  held  in 
queue  to  identify  ZYB  flagged  messages  for  removal.  Unfortunately,  this  capability  does 
not  exist  with  GPSS  and  prevents  the  author  from  modeling  the  AM  intercept  or  the 
combination  AM/ADM  intercept.  The  decision  to  continue  using  GPSS  was  based  on 
two  reasons;  one,  GPSS's  ease  of  use,  and  two,  that  the  modeling  of  the  ADM  feature 
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Figure  6.  Fleet  Broadcast  -  Simplified  Single  Server  Model 

would  qualitatively  show  the  intercept  effects  that  the  author  considered  pertinent  to  the 
research. 

The  author  also  wishes  to  reemphasize  that  the  results  given  are  qualitative  in 
nature.  To  validate  the  quantitative  results  of  the  simulation  model  would  require  re¬ 
sources  not  available  at  the  time  of  the  research  (i.e.  historical  analytical  data,  actual 
NAVCOMPARS  operation  time  under  experimental  conditions). 

3.  ADM  Model  Design 

The  single  server  model  proposed  in  Ref.  21  is  based  on  a  standard  teletype 
transmission  circuit  operating  at  seventy-five  baud.  To  simulate  this  model  using  GPSS 
will  require  the  following  features: 

•  transaction  generation  and  termination 

•  queue  entrance  and  departure 

•  simulation  of  transmission  time 

•  ADM  intercept  capability 

Transaction  generation  and  termination  is  easily  accomplished  using  the  GPSS 
commands  generate  and  terminate.  The  generate  command  will  simulate  message  arrival 
at  a  desired  rate;  this  is  the  first  phase  of  generation  mentioned  above.  The  second 
phase,  the  assignment  of  attributes,  is  accomplished  using  three  assign  commands.  The 
three  attributes  to  be  used  are  message  precedence  (routine,  priority,  immediate), 
administrative  operational  designation,  and  message  length  in  characters.  Note  that 
both  the  simulated  message  arrival  rates  and  attributes  can  be  varied  to  simulate  desired 
conditions;  these  options  will  be  used  to  demonstrate  the  model  features. 

26 


Queue  entrance  and  departure  is  simulated  through  use  of  the  queue  and  depart 
commands.  Use  of  the  queue  command  produces  useful  statistics  mentioned  above. 

Simulation  of  transmission  time  is  done  using  the  advance  command.  Using 
eight  bits  per  character,*  multiplied  by  the  individual  message  length  gives  the  message 
length  in  bits.  Dividing  this  value  by  the  capacity  of  the  transmission  circuit  gives 
transmission  time;  the  transmission  capacity  used  was  seventy-five  baud.  [Ref.  22: 
pp.343-345] 

The  simulation  of  an  ADM  command  is  done  using  multiple  test  commands. 
The  first  test  command  is  used  as  a  trigger  that  simulates  a  redirect  when  the  queue  level 
reaches  a  certain  level.  Once  a  redirect  is  started  the  second  and  third  test  commands 
check  for  message  type  (administrative  or  operational)  and  precedence  respectively.  See 
Appendix  B,  Simulation  Model  Specifications,  for  the  actual  GPSS  code  and  an  accom¬ 
panying  flow  chart  showing  diagrammatic  model  flow. 


8  Actual  bits  per  message  character  is  7.42  for  Baudot  code  TTY's  [Ref.  22:  p.342|.  This  is 
rounded  up  to  eight  bits  due  to  GPSS  requirement  for  advance  block  values  to  be  intergers  [Ref. 
19:  p.26|. 


V.  SIMULATION  RESULTS  AND  ANALYSIS 


A.  INTRODUCTION 

The  purpose  of  a  simulation  model  is  to  allow  via  experimentation  understanding 
of  the  influence  of  different  parameters  and  variables  on  system  behavior.  By  varying 
these  parameters  it  is  hoped  that  the  researcher  can  develop  causal  relationships  which 
might  prove  helpful  in  understanding  the  simulated  system  as  a  whole.  In  this  chapter 
the  following  sections  are  included: 

1.  Simulation  Model  Test  Variables 

2.  Simulation  Model  Test  Results  and  Discussion 

B.  SIMULATION  MODEL  TEST  VARIABLES 

As  mentioned  in  the  previous  chapter,  the  simulation  model  used  in  this  research  is 
a  representation  of  a  single  output  channel  on  the  Fleet  Broadcast  with  the  capability 
of  activating  an  ADM  altroute.  Within  this  representation  of  the  Fleet  Broadcast 
channel,  there  are  several  parameters  which  can  be  manipulated  to  test  the  model  under 
varying  conditions. 

1.  Model  Variables 

In  this  simulation  model  there  are  two  types  of  variables  which  can  be  con¬ 
trolled;  the  first  variable  types  are  the  attributes  assigned  each  individual  message  on 
generation  by  the  generate! assign  block  sequence.  These  variables  are: 

•  Message  Precedence 

There  are  four  message  precedence  levels  in  use  in  the  NAVY:  Routine, 
Priority,  Immediate,  and  Flash  (in  increasing  priority).  Of  these  four,  only  three  , 
Routine,  Priority,  and  Immediate,  can  be  categorized  as  administrative  messages 
[Ref.  23:  p.4-2j.  To  reflect  this,  message  precedence  is  granted  through  the  assign 
block  using  the  relative  distributions  and  a  random  number  generator.  The  user 
has  the  ability  to  vary  the  distribution  of  each  message  precedence  to  reflect  the 
precedence  characteristics  of  any  simulation  test  run. 

•  Message  Length 

Through  the  use  of  the  second  assign  block  it  is  possible  to  dictate  the 
range  of  total  characters  per  message.  In  this  simulation  model,  character  assign¬ 
ment  is  given  by  a  continuous  function  with  a  user  determined  low  end  and  high 
end  number  of  characters  per  message.  In  Ref.  24  ,  CNTC's  Semi-Annual  Sum¬ 
mary  of  Naval  Telecommunications  Performance,  the  approximate  average  mes¬ 
sage  length  was  1962  characters;  this  figure  was  used  as  a  rough  indicator  on  where 
to  start  length  variation. 


•  Ratio  of  Administrative  to  Operational  Messages 

The  designation  of  whether  a  message  is  administrative  or  operational  is 
determined  in  the  third  and  final  assign  block.  By  varying  the  percentage  of  ad¬ 
ministrative  message  traffic  ,  the  researcher  can  affect  the  ratio  of  administrative 
to  operational  traffic  to  determine  if  there  are  any  effects  on  the  measured  outputs. 

The  second  variable  type  is  external  to  the  actual  messages;  these  are  related  to 
the  message  mean  arrival  rates  and  the  activation  of  the  administrative  intercept  com¬ 
mand. 

•  Message  Arrival 

Message  arrival  can  be  manipulated  in  two  manners;  the  first  is  by  the 
setting  of  the  mean  time  between  message  generation.  This,  in  effect,  is  the  con¬ 
trolling  of  the  message  mean  arrival  rate  to  the  system.  The  second  modification 
is  accomplished  by  specifying  a  spread  modifier  about  the  mean  time  between 
message  generation.  Using  this  feature  makes  the  arrival  rate  less  constant  and 
more  realistic. 

•  Administrative  Intercept  Command 

The  activation  of  the  administrative  intercept  command  can  also  be  modi¬ 
fied  in  two  ways.  First,  the  model  can  be  executed  with  the  intercept  command 
being  invoked  at  any  specified  queue  level;  in  the  actual  GPSS  code,  the  intercept 
command  is  set  to  activate  w’hen  the  output  queue  equals  a  user  determined  level. 
The  second  modification  to  the  intercept  command  is  precedence  oriented;  the  user 
can  set  the  model  to  intercept  administrative  messages  at  different  precedence  levels 
using  test  blocks. 

2.  Simulation  Test  Run  Coding 

To  identify  the  various  simulation  test  runs,  it  was  necessary  to  develop  a  means 
of  differentiating  between  the  runs.  The  coding  scheme  is  illustrated  in  Figure  7  on  page 
30.  Test  Run  Designation  is  the  identification  number  for  the  simulation  run.  Total 
Message  Arrivals  for  24  Hour  Period  is  the  cumulative  total  of  messages  to  be  generated 
by  the  simulation  system.  Message  Interarrival  Time  Modifier  (%)  is  the  control  of 
variance  about  the  message  mean  interarrival  time;  message  mean  interarrival  time  is 
total  seconds  per  day  (86400)  divided  by  the  total  messages  per  day.  Administrative 
Messages  (%)  in  Total  Traffic  indicates  the  percentage  of  total  arriving  messages  that 
are  administrative  in  nature.  Queue  Level  at  which  Intercept  is  Activated  is  set  by  the 
user;  Precedence  of  Administrative  Messages  Affected  is  also  selected  by  the  user.  Two 
factors  are  not  included  in  the  coding  scheme;  these  are  the  message  precedence  distrib¬ 
ution  and  message  character  ranges.  It  will  be  assumed  that  the  message  precedence 
distribution  is  0.33  Routine,  0.33  Priority,  and  0.33  Immediate,  unless  otherwise  speci¬ 
fied;  similarly,  the  message  character  range  will  be  assumed  to  be  100-2500.  The  message 
character  range  is  continuous  and  message  character  values  assigned  are  distributed 
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Test  #AA/BBBB/CC/DD/EEEZ 
Parameters: 

AA  -  Test  Run  Number  Designation 
BBBB  -  Total  Message  Arrival  for  24  Hour  Period 
CC  -  Message  Mean  Interarrival  Time  Modifier  (%) 
DD  -  Administrative  Messages  (%)  in  Total  Traffic 
EEE  -  Queue  Level  at  which  Intercept  is  Activated 
Z  -  Precedence  of  Administrative  Messages  Affected 
(includes  selected  precedence  and  lower) 


Figure  7.  Simulation  Test  Run  Coding  Scheme 

uniformly  over  the  indicated  range.  Should  test  parameters  for  precedence  distribution 
or  message  character  range  require  alteration  the  new  values  will  be  indicated  in  the 
applicable  section  and  on  the  resulting  graphs. 

3.  Simulation  Test  Run  Results 

As  mentioned  in  the  previous  chapter,  the  result  of  the  simulation  runs  will  be 
used  for  comparative  analysis  using  graphs  of  the  following  factors: 

•  Total  Message  Throughput 

•  Output  Channel  Queue  Level  (noncumulative) 

•  Total  Administrative  Messages  Intercepted 


Additional  graphs  will  also  be  used  to  further  examine  output  characteristics.  Preced¬ 
ence  distribution  of  messages  transmitted  (throughput)  will  be  provided  with  the  indi¬ 
vidual  cumulative  precedence  levels  over  the  test  period.  The  breakdown  of 
administrative  versus  operational  messages  transmitted  will  also  be  provided.  See 
Figure  8  on  page  3 1  for  an  explanation  of  test  graph  terminology. 


TEST  GRAPH  LEGEND** 


A.  THROUGHPUT  GRAPH 

1)  THROUGHPUT  -  Messages  transmitted  (cumulative) 

2)  QUEUE  -  Messages  in  queue  (noncumulative) 

3)  ADMIN  -  Administrative  messages  intercepted 

(cumulative) 

B.  MESSAGE  PRECEDENCE  GRAPH 

1)  ROUTINE  -  Routine  messages  transmitted  (cumulative) 

2)  PRIORITY  -  Priority  messages  transmitted  (cumulative) 

3)  IMMEDIATE  -  Immediate  messages  transmitted 

(cumulative) 

C.  MESSAGE  TYPE  GRAPH 

1)  ADMIN-XMIT  -  Administrative  messages  transmitted 

(cumulative) 

2)  OPS-XMIT  -  Operational  messages  transmitted 

(cumulative) 

**-all  graphs  are  based  on  a  24  hour  run  time  with  data 
generated  every  2  hours. 


Figure  8.  Test  Graph  Legend 
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C.  SIMULATION  MODEL  TEST  RESULTS  AND  DISCUSSION 


In  this  section  the  results  of  simulation  test  runs  will  be  presented  graphically. 

1.  Message  Precedence  Distribution  Variation 

In  this  set  of  simulation  tests  all  parameters  were  held  constant  with  the  excep¬ 
tion  of  the  precedence  distributions.  Three  tests  were  conducted  using  the  following 
precedence  distributions: 

•  #29  -  0.45  Routine,  0.40  Priority,  0.15  Immediate 

•  #27  -  0.15  Routine,  0.40  Priority,  0.45  Immediate 

•  #28  -  0.05  Routine,  0.40  Priority,  0.55  Immediate 

Average  utilization  for  the  system  test  runs,  using  average  message  arrival  rate,  divided 
by  the  average  message  service  rate,  is  [Ref.  20:  p.288): 

•  #29  -  1.31 

•  #27  -  1.31 

•  #28  -  1.32 

The  results  are  presented  in  Figure  9  on  page  33. 

From  inspection  of  the  results  there  appears  to  be  no  appreciable  differences 
when  using  throughput,  queue  level,  and  intercepted  administrative  messages  as  meas¬ 
ures  of  performance.  This  is  not  completely  surprising  given  that  only  the  precedence 
distribution  was  altered.  Keeping  in  mind  that  this  is  a  preemptive  system  with  higher 
precedence  messages  receiving  first  servicing,  it  can  be  hypothesized  that  the  sequence 
of  individual  messages  being  processed  changed  when  the  distribution  was  altered.  For 
example,  in  Test  #28  with  fifty-five  percent  Immediate  and  forty  percent  Priority  mes¬ 
sages,  it  is  hypothesized  that  the  majority  of  Routine  traffic  is  either  in  queue  or  has 
been  intercepted  if  an  administrative  message  altroute  had  been  in  effect.  This  hypoth¬ 
esis  appears  valid  by  examining  the  precedences  of  messages  transmitted  in  Figure  10 
on  page  34.  The  Routine  messages  in  Test  #28  are  never  transmitted  due  to  their  low 
priority.  In  Test  #29  with  only  fifteen  percent  Immediate  messages,  there  are  more 
Routine  messages  processed  through  the  system  without  preemption;  this  is  illustrated 
in  Figure  10  on  page  34. 
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Message  Precedence  Distribution  Variation 


2.  Message  Length  Variation 

The  number  of  characters  present  in  a  message  directly  determines  the  trans¬ 
mission  time  required  on  the  output  channel  assigned.  In  this  test  set,  three  runs  were 
conducted  using  the  following  ranges: 

•  #30  -  100-1500  characters  per  message 

•  #6  -  100-2500  characters  per  message 

•  #31  -  100-3500  characters  per  message 


The  reader  is  again  reminded  that  the  character  values  assigned  are  uniformly  distributed 
over  the  indicated  continuous  character  range. 

The  results  from  this  set  of  tests,  illustrated  in  Figure  1 1  on  page  36,  show  dis¬ 
tinct  differences  in  all  three  quantities  measured.  Precedences  transmitted  and  message 
types  transmitted  are  illustrated  in  Figure  12  on  page  37  and  Figure  13  on  page  38. 
At  the  lowest  range,  in  Test  #30,  throughput  was  maximized  with  few  messages  held  in 
queue;  because  of  this,  it  was  not  necessary  to  activate  an  administrative  message  inter¬ 
cept.  Precedences  transmitted  in  Test  #30  showed  corresponding  increases  at  all  levels. 
There  was  also  an  appreciable  number  of  administrative  messages  transmitted.  Widen¬ 
ing  the  range  to  100-2500  characters  in  Test  #6  shows  a  drop  in  throughput  with  a 
buildup  in  queue  level.  Messages  of  Routine  precedence  were  not  transmitted  until  hour 
ten;  this  is  the  approximate  point  where  the  intercept  was  activated.  The  activation  re¬ 
duced  message  arrival  into  the  queue  allowing  Routine  messages  in  queue  the  opportu¬ 
nity  to  be  transmitted.  It  should  also  be  noted  that  the  administrative  message  intercept 
in  this  character  range  aided  in  lowering  the  queue  level  when  activated.  Test  #31,  at 
100-3500  characters,  illustrates  an  appreciable  drop  in  throughput  with  increases  in  both 
queue  level  and  intercepted  administrative  messages.  Lower  priority  Routine  messages 
had  little  possibility  of  being  transmitted;  correspondingly,  both  administrative  and  op¬ 
erational  messages  transmitted  decreased.  In  this  run  the  activation  of  the  intercept 
showed  little  efTect  in  lowering  queue  level.  With  the  increase  in  message  characters  it 
is  felt  that  the  benefits  of  the  intercept  are  reduced  by  the  slowdown  in  message  proc¬ 


essing. 


Results  of  these  tests  show  that  the  number  of  characters  in  arriving  messages 
affects  the  message  throughput  and  lessens  the  effectiveness  of  the  adminstrative  inter¬ 
cept  in  reducing  queue  level  as  the  number  of  average  message  characters  increases. 


3.  Message  Type  Variation 

The  effectiveness  of  an  administrative  message  intercept  is  directly  related  to  the 
percentage  of  administrative  messages  in  the  arriving  traffic.  This  effect  was  demon¬ 
strated  using  the  following  variations  in  percentage  administrative  traffic: 

•  #4-20% 

•  #5-25% 

•  #6  -  30% 

•  #7-35% 

•  #8-40% 

•  #9-45% 

The  results  of  these  test  runs  are  illustrated  in  Figure  14  on  page  40  and  Figure  15  on 
page  41.  Precedences  transmitted  during  these  tests  are  illustrated  in  Figure  16  on  page 
42  and  Figure  17  on  page  43.  Message  types  transmitted  are  illustrated  in  Figure  18 
on  page  44  and  Figure  19  on  page  45.  From  observation,  it  is  apparent  that  as  per¬ 
centage  administrative  traffic  increased  so  does  the  effectiveness  of  the  intercept  in  re¬ 
ducing  queue  level.  Additionally,  this  effectiveness  leads  to  higher  amounts  of 
intercepted  messages  at  the  Screening  Board  printer. 

Precedences  transmitted  show  decreasing  numbers  of  Priority  and  Immediate 
traffic  with  increasing  Routine  messages  being  transmitted  as  the  percentage  adminis¬ 
trative  traffic  increases.  The  cause  of  this  behavior  is  that  an  intercept  of  administrative 
messages  while  at  a  high  percentage  of  administrative  traffic,  will  remove  all  adminis¬ 
trative  Priority  and  Immediate  traffic.  This  decrease  in  higher  precedence  messages  leads 
to  the  transmission  of  lower  precedence  traffic  already  held  in  queue.  Administrative 
messages  transmitted  also  show  an  increase  in  the  Message  Types  Transmitted  graph 
with  operational  messages  decreasing.  This  is  the  result  of  the  sheer  increase  of  per¬ 
centage  administrative  traffic  in  each  test  run.  Note,  however,  that  once  an  intercept  is 
activated  the  amount  of  administrative  transmitted  drops  until  finally  no  administrative 
traffic  is  transmitted.  This  would  allow  the  possibility  of  higher  throughput  for  opera¬ 
tional  traffic;  this  is  shown  by  the  increased  rate  of  operational  messages  transmitted. 


Figure  17.  Precedences  Transmitted  -  Test  #7,  #8,  #9 
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4.  Message  Arrival  Rate  Variation 

In  this  phase  of  testing,  simulations  were  conducted  in  two  parts;  the  first  part 
included  variation  of  total  messages  arrived  over  a  twenty-four  hour  period.  The  second 
part  involved  variations  in  the  spread  modifier  about  the  mean  interarrival  time. 

a.  Arrival  Rate  Variation 

This  test  sequence  was  conducted  at  the  following  daily  arrival  rates: 

•  #6  -  800  messages  per  day 

•  #1  -  1000  messages  per  day 

The  results  of  the  two  runs  are  in  Figure  20  on  page  47.  The  results  indicate  two  dif¬ 
ferences.  The  first  difference  is  that  the  administrative  message  intercept  requires  an 
earlier  activation;  in  this  case,  activation  at  six  hours  for  1000  messages  per  day  and 
activation  at  ten  hours  for  800  messages  per  day.  The  second  difference  is  that  the 
higher  arrival  rate  of  Test  #1  reduces  the  effectiveness  of  the  intercept;  the  number  of 
messages  altrouted  will  not  be  sufficient  enough  to  reduce  the  queue  level.  At  the  lower 
arrival  rate,  the  intercept  does  aid  in  queue  level  reduction. 

b.  Variation  about  the  Mean  Interarrival  Time 

The  testing  in  this  set  was  conducted  at  the  following  percent  variation 
about  the  mean  interarrival  time: 

•  #15  -  10% 

•  #16-20% 

•  #17-25% 

•  #18-30% 

•  #19-40% 

•  #20-50% 

From  observation  of  Figure  21  on  page  48  and  Figure  22  on  page  49,  there  is  no  ap¬ 
preciable  difference.  Inspection  of  the  data  from  the  Precedences  Transmitted  and  the 
Message  Types  Transmitted  also  indicate  no  appreciable  difference.  The  data  shows 
minor  variation  of  one  or  two  messages  at  any  given  point  during  the  run.  This  phe¬ 
nomena  may  be  explained  by  the  Law  of  Large  Numbers  which  states  that  in  a  large 
sample,  the  probability  is  high  that  the  sample  mean  is  close  to  the  mean  of  the  parent 
population  {Ref.  25:  p.284|.  In  other  words,  given  a  parent  population  mean  message 
interarrival  time  with  a  large  sample  size,  the  amount  of  variance  (or  in  this  case,  spread 
modification)  will  have  little  effect  in  producing  a  sample  mean  interarrival  time  much 


Figure  20.  Message  Interarrival  Time  Variation 


J  different  from  the  parent  population  mean.  This  would  explain  why  each  graph  appears 

almost  identical  regardless  of  the  spread  modification. 
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Figure  22.  Message  Interarrival  Time  Spread  Modifier  Variation  (b) 


5.  Administrative  Intercept  Command  Variation 

The  administrative  intercept  command  can  be  altered  in  two  ways;  the  first 
method  involves  the  timing  of  intercept  activation.  The  second  method  involves  the 
precedence  level  selected  for  the  intercept. 

a.  Administrative  Intercept  Command  Activation 

The  decision  of  when  to  activate  an  administrative  altroute  is  dependent  on 
what  the  system  manager's  definition  of  a  congested  queue  is.  In  this  set  of  simulations 
the  message  arrival  rate  was  set  at  1000  messages  per  day  to  rapidly  congest  the  queue. 
For  testing  purposes,  the  following  activation  points  were  selected: 

•  #1-100  messages  in  queue 

•  #2-150  messages  in  queue 

•  #3  -  200  messages  in  queue 

Note  that  the  above  tests  were  run  at  Immediate  precedence  and  below.  See  Figure  23 
on  page  51  for  the  test  results.  Precedences  transmitted  is  shown  in  Figure  24  on  page 
52. 

The  first  noticeable  effect  is  that  the  earlier  the  command  activation  the 
lower  the  resultant  queue  size.  While  there  is  no  reduction  in  queue  size  the  intercept 
activation  prevents  the  queue  size  from  expanding  further.  In  the  previous  section  on 
message  arrival  rate,  it  was  pointed  out  that  at  1000  messages  per  day  the  activation  of 
an  intercept  did  not  reduce  a  queue  size  but  only  helped  control  it.  At  a  lower  message 
arrival  rate,  the  promptness  of  the  intercept  activation  will  determine  the  effectiveness 
of  queue  reduction. 

The  Precedence  Transmitted  graph  illustrates  that  the  earlier  activation  of 
an  intercept  quickens  the  transmission  of  Routine  messages  already  held  in  queue. 
These  Routine  messages  would  otherwise  remain  in  queue  while  higher  precedence 
messages  get  transmitted. 

The  Message  Type  Transmitted  graphs,  shown  in  Figure  25  on  page  53, 
show  minor  differences  in  adminstrative  messages  transmitted.  The  differences  are  due 
to  the  varying  amounts  of  administrative  messages  allowed  in  queue  prior  to  activation. 
For  example,  Test  #3  with  a  late  activation  at  200  messages  in  queue,  will  accumulate 
more  administrative  traffic  in  queue  prior  to  intercept  activation.  These  messages  are 
later  transmitted  after  activation  of  the  intercept. 


Figure  25.  Message  Types  Transmitted  -  Test  #1,  #2,  #3 


b.  Administrative  Intercept  Precedence  Variation 

This  set  of  tests  was  conducted  using  a  0.33  Routine,  0.33  Priority,  0.33 
Immediate  precedence  distribution  at  800  messages  per  day  mean  arrival  rate,  with  in¬ 
tercept  activation  at  a  queue  level  of  100  messages.  The  test  parameters  are: 

•  #10  -  Routine  precedence 

•  #1 1  -  Priority  precedence  and  below 

•  #12  -  Immediate  precedence  and  below 

The  results,  illustrated  in  Figure  26  on  page  55  demonstrate  that  the  pre¬ 
cedence  level  selected  for  the  intercept  will  directly  determine  the  effectiveness  of  the  in¬ 
tercept.  A  low  precedence  selection  will  decrease  the  effectiveness  of  the  intercept; 
conversely,  a  high  precedence  will  increase  intercept  effectiveness. 

The  Precedences  Transmitted  graph  in  Figure  27  on  page  56  shows  that  an 
intercept  set  at  a  higher  precedence  frees  more  lower  precedence  traffic  from  the  queue. 
In  essence,  the  operator  is  trading  higher  precedence  administrative  traffic  for  lower 
precedence  operational  traffic. 

Message  Types  Transmitted  shown  in  Figure  28  on  page  57  indicates  a 
higher  administrative  transmission  total  at  the  low  precedence  intercept.  In  this  case, 
the  higher  precedence  administrative  messages  are  blocking  the  lower  precedence  oper¬ 
ational  traffic. 

6.  Summary 

The  results  of  the  simulation  tests  demonstrate  that  the  effectiveness  of  an  ad¬ 
ministrative  intercept  is  related  to  the  specific  characteristics  of  arriving  messages.  The 
specific  characteristics  include: 

•  Precedence  Distribution  of  Arriving  Messages 

The  distribution  across  the  various  precedence  catagories  affects  the  effec¬ 
tiveness  of  the  intercept  based  upon  the  precedence  level  chosen  for  the  altroute. 
For  example,  an  administrative  intercept  of  routine  messages  will  have  minimal  ef¬ 
fect  if  the  arriving  traffic  is  primarily  Priority  or  Immediate  precedence. 

•  Message  Length 

The  transmission  time  required  for  a  message  is  directly  related  to  the 
number  of  characters  in  the  individual  messages;  traffic  composed  of  messages  with 
high  average  number  of  characters  will  move  slower  than  traffic  with  a  low  average 
number  of  characters.  Similarly,  the  longer  transmission  times  will  lead  to  higher 
queue  levels.  The  advantage  of  an  administrative  intercept  will  be  less  apparent  in 
traffic  with  a  a  higher  average  character  count;  the  intercept  may  slow  queue 
build-up,  but  most  likely  will  not  decrease  the  backlog.  The  average  message  length 
will  also  affect  the  precedence  levels  transmitted;  at  a  high  average  character  count 
the  possibility  of  transmitting  low  precedence  traffic  drops. 


•  Message  Type 

The  percentage  of  administrative  messages  in  arriving  traffic  directly  de¬ 
termines  the  effectiveness  of  any  intercept.  The  activation  of  an  intercept  in  a 
scenario  with  a  high  percentage  of  administrative  messages  will  have  marked  effects 
on  the  queue  levels  while  the  activation  in  traffic  with  low  percentage  leads  to  a 
lessened  effectiveness. 

•  Message  Interarrival  Time 

The  arrival  rate  of  messages  is  directly  related  to  the  effectiveness  of  an 
administrative  intercept.  The  effectiveness  will  run  from  high  in  a  low  message  ar¬ 
rival  rate  to  low  in  a  high  traffic  arrival  rate.  Additionally,  higher  traffic  rates  will 
require  prompt  action  from  operators/managers  since  the  queue  build-up  is  more 
rapid. 

Variations  about  the  mean  interarrival  time  demonstrated  no  appreciable 
effects  on  throughput;  as  mentioned  above,  this  can  be  explained  by  the  Law  of 
Large  Numbers. 

The  effectiveness  of  administrative  intercepts  is  also  related  to  the  timeliness  and 
scope  of  the  activation  command.  These  considerations  are: 

•  Command  Activation 

The  timeliness  of  activation  may  not  increase  the  actual  effectiveness  of  the 
intercept,  but  it  may  determine  whether  or  not  the  queue  reaches  a  critical  satu¬ 
ration  point.  Earlier  activation  may  aid  a  manager  in  controlling  a  potential 
backlog  problem.  Earlier  activation  may  also  help  in  freeing  lower  precedence  op¬ 
erational  traffic  in  queue. 

•  Precedence  Level 

The  precedence  level  selected  for  use  by  the  manager  will  control  the  scope 
of  the  intercept  command.  At  higher  precedence  levels  the  command  becomes 
much  more  inclusive.  This  can  be  consider  a  sensitivity  adjustment  of  the  intercept; 
this  would  allow  the  manager  to  more  effectively  tailor  the  intercept  to  the  traffic 
situation.  The  key  concept  is  that  using  administrative  intercepts  at  higher  pre¬ 
cedence  levels  frees  the  lower  precedence  operational  traffic. 


VI.  ADMINISTRATIVE  INTERCEPT  CONSIDERATIONS 

A.  INTRODUCTION 

The  decision  to  activate  an  administrative  intercept  is  a  complicated  one;  it  requires 
much  more  forethought  than  the  simple  observation  of  the  queue  level  of  an  output 
channel  on  the  Fleet  Broadcast.  It  is  proposed  by  the  author  that  the  decision  on  when 
activate  an  intercept  is  composed  of  two  distinct  phases;  the  first  is  the  guidance  and 
policy  development  phase.  The  second  phase  is  the  actual  on-station  decision  making 
using  the  guidance  and  policy  promulgated.  These  phases  will  be  discussed  in  the  fol¬ 
lowing  sections. 

B.  THE  DEVELOPMENT  OF  GUIDANCE  AND  POLICY 

The  decisions  on  how  to  utilize  a  tool  like  the  administrative  intercept  are  very 
complicated.  In  Glenn's  research  on  methodology  for  evaluating  the  effectiveness  of  an 
administrative  intercept  he  states  that  there  are  multiple  performance  attributes  to  be 
evaluated  [Ref.  21:  p.50].  He  proposes  that  the  decision  process  for  actuating  an  inter¬ 
cept  is  composed  of  the  attributes  listed  in  Figure  29  on  page  60  [Ref.21:  p.52j. 

Note  that  the  hierarchy  of  attributes  Glenn  suggests  is  applicable  to  the  development 
and  implementation  of  a  new  traffic  management  option.  For  a  feature  already  installed 
in  the  fleet,  like  administrative  intercept,  the  applicable  attributes  would  be  system  ef¬ 
fectiveness,  Navy  acceptance,  and  cost  to  employ  (not  including  initial  costs). 

Utilizing  these  attributes  the  policy  makers  can,  using  Multiattribute  Utility  Analy¬ 
sis  [Ref.  26]  or  the  Analytical  Hierarchy  Process?  [Ref.  27  and  Ref.  28],  assign  a  prefer¬ 
ence  value  by  weighting  the  attributes  individually.  In  this  process  the  policy  makers  can 
directly  influence  the  decision  making  process,  emphasizing  the  factors  deemed  critical. 
For  example,  by  freighting  system  effectiveness  heavily,  a  policy  can  be  generated  which 
is  tailored  to  ensure  system  effectiveness  over  the  other  choices. 

Upon  completion  of  the  attribute  analysis,  a  policy  with  proposed  thresholds  and 
procedures  can  be  promulgated  to  the  operators  and  managers  at  the  NAVCAMS. 

9  See  Appendix  C  for  a  brief  explanation  of  the  concepts  behind  Multiattribute  Utility  Anal¬ 
ysis  and  the  Analytical  Hierarchy  Process. 
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OVERALL  VALUE 


SYSTEM  DEVELOPMENT  COSTS  TO  NAVY 

EFFECTIVENESS  CONSIDERATIONS  EMPLOY  ACCEPTANCE 

I  I  I 

-UTILIZATION  -IN-HOUSE  -INITIAL 

-SPEED  OF  SERVICE  -REVISION  TIME  -RECURRING 

-QUEUE  TIME  -OPERATING 

-SERVICE  TIME  -TEST  &  EVALUATION  -MAINTENANCE 

-LENGTH  OF  QUEUE  -INTEROPERABILITY 

-NUMBER  OF  MESSAGES 

Figure  29.  Hierarchy  of  Attributes 

C.  ON-STATION  DECISION  MAKING 

Once  a  policy  is  promulgated  it  is  the  responsibility  of  the  operators  and  managers 
to  ensure  that  it  is  carried  out.  However,  the  perfect  conditions  under  which  the  policy 
was  generated  may  not  exist  at  the  user  level;  it  is  for  this  reason  that  the  author  re¬ 
commends  that  any  policy  regarding  administrative  intercept  be  advisory.  The  issuance 
of  an  advisory  guidance  vice  a  firm  set  of  rules  allows  the  operators  to  work  effectively 
in  even  the  most  unpredictable  set  of  circumstances. 

At  the  user  level,  any  good  decision  making  process  must  include  all  information 
available.  The  external  factors  and  internal  NAVCOMPARS  factors  mentioned  in 
Chapter  III  must  be  included.  The  transmission  system  in  use  also  will  be  a  factor  in 
the  process.  The  characteristics  of  the  arriving  message  traffic  was  shown  in  the  previ¬ 
ous  chapter  to  be  extremely  infiucncial  in  determining  the  relative  effectiveness  of  an 
intercept  action.  All  the  above  factors  combined  with  the  various  intercept  command 
variations  (different  activation  levels,  varied  precedence  levels)  will  impact  heavily  upon 


the  decision  making  process.  The  relationship  emphasizing  the  interdependence  of  all 
these  factors,  is  highlighted  in  Figure  30  on  page  62. 

Using  the  above  listed  information,  it  is  possible  for  the  managers  and  operators, 
working  within  the  guidance  of  CNTC,  to  reach  a  decision  on  intercept  activation  which 
would  be  both  responsive  and  effective  at  the  local  level.  See  Figure  3 1  on  page  63  for 
an  illustration  of  the  proposed  process.  The  policy  development  is  comprised  of  the  se¬ 
veral  steps;  the  first  step  is  the  determination  of  applicable  criteria  or  attributes.  Using 
either  Multiattribute  Utility  Analysis,  the  Analytical  Hierarchy  Process,  or  any  applica¬ 
ble  analysis  process,  the  criteria  can  then  be  evaluated  with  the  end  result  being  the 
generation  of  criterion  for  policy.  It  is  then  recommended  that  an  advisory  guidance, 
based  on  those  criterion,  be  promulgated.  The  NAVCAMSs,  using  the  advisory  guid¬ 
ance,  can  then  take  into  account  all  information  held  on-station  and  forge  an  activation 
decision  which  is  influenced  by  both  upper  echelon  policy  and  local  communication 
conditions. 

It  should  be  noted  that  this  decision  process  can  be  readily  adapted  to  other  traffic 
management  decisions.  The  factors  to  be  considered,  both  at  the  policy  making  level 
and  on-station,  may  require  modification  depending  on  the  particular  decision  to  be 
evaluated. 
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E  *  Effectiveness  of  an  administrative  intercept 


E  -  F(AA,BB,CC,DD,EE,XX,YY,ZZ) 


AA  -  Precedence  Distribution 
BB  -  Message  Length  (avg)  of  Arriving  Traffic 
CC  -  Percent  Administrative  Message 
DD  -  Message  Arrival  Rate 
EE  -  Intercept  Command 

1)  Queue  level  selected 

2)  Precedence  level  selected 
XX  -  External  Factors  (Chapter  III) 

YY  -  NAVCOMPARS  Internal  Factors  (Chapter  III) 
ZZ  -  Transmission  Considerations  (HF  vs  SAT) 


Figure  30.  Considerations  for  Implementing  an  Administrative  Intercept 
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Figure  31.  Decision  Making  Process  Tor  Administrative  Intercept 


VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  FINDINGS 

The  guidance  promulgated  by  CNTC  in  Ref.  11  presents  an  activation  scheme  for 
an  administrative  message  intercept  based  on  Fleet  Broadcast  output  channel  queue 
backlog.  Subsequent  message  reentry  of  intercepted  message  is  also  based  on  queue 
backlog  level. 

The  solicited  responses  from  the  individual  NAVCAMS  summarized  in  Chapter  III, 
were  for  the  most  part  negative.  Frequent  comment  was  made  on  the  following  issues: 

•  the  need  for  thresholds  oriented  with  the  particular  Fleet  Broadcast  transmission 
means  in  use  (HF/Satellite) 

•  the  effectiveness  and  efficiency  of  the  administrative  message  intercept  as  a  traffic 
management  device  in  its  present  form 

•  perceived  erosion  of  traffic  management  decision  making  at  the 
FLTCINCs/NAVCAMS  level 

•  disregard  for  on-station  watchteam  expertise 

•  the  failure  of  the  CNTC  threshold  to  take  into  account  the  special  requirements 
and  causes  of  each  traffic  congestion  problem 

Based  on  the  NAVCAMS's  responses  and  the  conducted  research  of  this  thesis  it 
appears  that  the  NAVCAMS's  comments  are  generally  well  founded.  Due  to  differences 
in  HF  and  Satellite  operation  requirements  it  is  imperative  that  there  be  specialized 
thresholds  for  working  in  each  environment.  It  may  also  be  necessary  to  develop 
thresholds  for  each  individual  NAVCAMS  based  on  the  local  propagation  conditions. 
The  individual  tailored  thresholds  should  take  into  account  the  differing  sequence  on 
intercept  activation  steps  (HF-intercept/overload  versus  Satellite-overload/intercept). 

The  second  item  listed  above  questioned  the  most  current  configuration  of  the  ad¬ 
ministrative  intercept.  As  mentioned  in  Chapter  II,  the  activation  of  an  intercept  results 
in  the  altrouting  of  qualifying  messages  to  the  Screening  Board  printer  for  further 
screening.  This  process  would  appear  to  be  both  equipment  and  manpower  intemsive. 
The  intercept  results  in  additional  printer  requirements  as  well  as  the  personnel  required 
to  review  the  messages  by  hand.  Reentry  requirements  are  also  manpower  intensive 
since  it  requires  that  the  Service  Clerk  key  individual  messages  for  reentry  into  the 
NAVCOMPARS.  One  recommendation  by  NAVCAMS  LANT,  was  that  alternate 
routing  to  a  magnetic  tape  storage  unit  be  used  in  place  of  the  Screening  Board  printer 


[Ref.  14].  This  recommendation  fails  to  address  message  screening.  Altrouting  directly 
to  a  storage  medium  (i.e.  magnetic  tape  or  disk)  without  screening  fails  to  remove  mes¬ 
sages  from  the  system;  this  type  of  altroute  would  only  postpone  reentry  until  queue 
levels  permit. 

One  improvement  on  the  horizon  is  the  Automatic  Message  Screening  Subsystem 
(AMSS)  scheduled  for  NAVCOMPARS  Release  13.0  software  [Ref.  6],  AMSS  should 
improve  the  current  Screening  Board  procedure  by  electronically  allowing  message 
screening  by  video  terminals  with  the  capability  of  on-line  reentry  of  messages  if  desired 
[Ref.  29].  Additionally,  AMSS  will  reduce  the  requirement  for  message  printing  and 
sorting,  and  Service  Clerk  reentry  procedures  for  intercepted  messages. 

The  final  three  points  can  be  addressed  as  a  group.  The  imposition  of  a  firm 
threshold  guidance  by  CNTC  was  felt,  by  the  NAVCAMS,  to  reduce  traffic  management 
options.  By  virtue  of  being  on-station  it  was  felt  that  the  watchteams  would  have  a  more 
complete  'big  picture'  of  the  traffic  situation  in  their  individual  COMM AREAs.  The 
watchteams  would  also  have  more  information  on  equipment  resources  and/or  limita¬ 
tions,  and  be  in  direct  communication  with  the  end  users,  the  fleet  units.  The 
watchteams  would  also,  through  the  traffic  monitoring  capabilities  of  the 
NAVCOMPARS,  be  appraised  on  the  characteristics  of  the  arriving  traffic.  The  char¬ 
acteristics  listed  in  Figure  30  on  page  62  of  Chapter  VI  were  shown,  individually  or  in 
combination,  to  affect  the  effectiveness  of  an  activated  administrative  intercept. 

Given  this  information  on  traffic  characteristics,  equipment  resources,  and  the  needs 
of  the  fleet  units  it  appears  that  the  NAVCAMS's  watchteams,  using  their  combined 
expertise  and  experience,  would  be  better  suited  to  judge  when  to  activate  an  adminis¬ 
trative  message  intercept  at  the  user  level. 

This  in  a  sense  is  a  shift  from  an  upper  echelon  controlled  activation  to  a  user  con¬ 
trolled  activation  scheme.  In  Chapter  VI,  it  is  suggested  that  a  two  phase  decision 
process  be  utUIzccL  Using  the  two  recommended  phases  would  allow  CNTC  to  empha¬ 
size  its  priorities,  but  at  the  same  time  allow  the  users,  the  NAVCAMS's,  a  certain 
amount  of  flexibility  to  deal  with  a  dynamic  environment.  It  is  the  conclusion  of  this 
thesis  that  such  a  process  would  be  beneficial  to  all  parties  concerned.  Through  the  use 
of  this  proposed  scheme  it  is  hoped  the  fleet  units,  the  end  users,  can  be  assured  timely 
delivery  of  vital  message  traffic. 


B.  POSSIBLE  FUTURE  TOPICS 

From  the  simulation  test  runs  it  was  apparent  that  message  characteristics  can  affect 
message  throughput.  One  characteristic,  the  percentage  of  administrative  messages  in 
arriving  traffic,  showed  strong  influence  on  the  effectiveness  of  an  administrative  mes¬ 
sage  intercept.  In  his  research,  Glenn  states  that  fifty  percent  of  all  arriving  traffic  may 
be  administrative  in  nature  [Ref,  21:  p.57].  If  this  were  indeed  the  case  it  would  appear 
that  the  effectiveness  of  an  intercept  is  being  held  artificially  low  by  the  incorrect  classi¬ 
fication  of  messages.  CNTC  is  in  the  process  of  developing  an  policy  where  message 
originators  will  be  required  to  classify  a  message  as  administrative  or  operational  [Ref. 
30].  The  current  policy  assumes  that  all  messages  are  operational  unless  marked  as  ad¬ 
ministrative.  Although  the  marking  of  both  administrative  and  operational  messages 
has  no  real  effect  in  terms  of  message  handling  procedures,  it  is  hoped  that  the  origina¬ 
tors  will  be  forced  to  more  closely  screen  their  messages  before  marking  one  as  opera¬ 
tional.  One  possible  research  topic  is  to  compare  user's  perceptions  of  what  constitutes 
an  administrative  message  or  an  operational  message.  Using  this  data  and  data  from 
CNTC  it  may  be  possible  to  develop  criteria  to  use  in  defining  message  categories. 

Another  traffic  characteristic  which  affected  throughput  was  message  length.  By 
reducing  message  lengths  throughput  and  speed  of  service  should  improve.  Is  there  a 
way  of  decreasing  average  message  length?  Several  recurring  Navy  messages  have  a  set 
format  which  seems  to  reduce  message  length.  Examples  are  Casualty  Reports 
(CASREP)  used  for  reporting  equipment  casualties  or  degradation  and  the  NEURS 
(Navy  Energy  Usage  Reporting  System)  report  used  for  reporting  fuel  consumption  and 
accounting.  Both  reports  are  format  oriented  and  would  seem  to  reduce  message 
lengths.  The  possibility  of  increasing  use  of  format  messages  and  the  potential  gains  in 
terms  of  throughput  and  speed  of  service  should  be  investigated. 

With  the  increased  use  of  Decision  Support  Systems  (DSS)  it  may  be  possible  to 
commence  implementation  in  the  Naval  Telecommunications  System.  One  possibility 
is  the  use  of  DSS  with  the  AMSS;  this  would  further  decrease  the  need  for  manpower 
since  the  proposed  AMSS  requires  experienced  personnel  to  man  the  video  terminals. 

The  final  proposed  topic  is  related  to  the  user  level  decision  making  criteria  shown 
in  Chapter  VI.  Given  this  wide  set  of  variables,  it  may  be  possible  to  develop  a  detailed 
flowchart  which  can  lead  a  user  step-by-step  to  a  valid  activation  decision  or  provide  a 
foundation  for  DSS  implementation. 


APPENDIX  A.  NAVCOMPARS  -  AN  OVERVIEW 


The  Naval  Communications  Processing  and  Routing  System  (NAVCOMPARS)  is 
an  automated  system  which  serves  as  an  interface  between  the  Naval  Telecommuni¬ 
cation  System  (NTS)  and  the  Defense  Communication  System  (DCS).  In  this  appendix, 
the  following  areas  will  be  addressed: 

1.  Functional  Interface  Areas 

2.  NAVCOMPARS  Subsystems 

A  FUNCTIONAL  INTERFACE  AREAS 

The  NAVCOMPARS  is  comprised  of  eight  functional  interface  areas  which  interact 
with  the  system  processing  actions.  These  areas  include: 

1.  Message  Center  (MSGCEN) 

2.  Service  Center  (SVCEN) 

3.  Fleet  Center  (FLTCEN) 

4.  Computer  Center  (COMPCEN) 

5.  Technical  Control  (TECHCTL) 

6.  Receiver  Site  (RECSITE) 

7.  Top  Secret  (TS)  Control 

8.  Operations  Office  (OPSOFF) 

1.  Message  Center  (MSGCEN) 

The  primary  purpose  of  the  MSGCEN  is  serving  as  the  delivery  and  acceptance 
source  for  over-the-counter  traffic.  These  services  are  provided  for  local  users;  local  us¬ 
ers  may  include  tenant  commands  and/or  fleet  units  (when  under  "guard"  or  "protect" 
coverage  by  the  NAVCAMS).lO  The  MSGCEN  interfaces  with  the  NAVCOMPARS 
using  optical  character  readers  (OCR),  video  data  terminals  (VDT),  teletype  (TTY),  and 
medium-speed  line  printers!  [Ref.  8:  pp.3-8) 

10  'Guard'  and  'Protect'  are  different  levels  of  coverage  provided  by  the  NAVCAMS  for  the 
local  users.  'Protect'  coverage  means  that  the  NAVCAMS  only  receives  traffic  for  the  local  users; 
'guard'  is  similar  to  "protect",  but  includes  routing  (extra  copies  and  internal  distribution)  for  the 


2.  Service  Center  (SVCEN) 

The  SVCEN's  main  purpose  is  to  service  and/or  correct  messages  which  are  re¬ 
jected  by  the  system.  The  SVCEN  also  processes  Broadcast  Service  Requests  (BSR)  for 
units  requiring  retransmission  of  missed  or  garbled  messages.  NAVCOMPARS  inter¬ 
faces  are  through  VDTs,  line  printers,  teleprinters,  and  paper  tape  readers/punches. 
[Ref.  8:  pp.8-11] 

3.  Fleet  Center  (FLTCEN) 

The  FLTCEN  serves  as  the  major  terminal  area  for  low  speed  communication 
channels;  this  responsibility  entails  monitoring  and  operating  of  active  channels.  Active 
channels  include  off-line  and  on-line  quality  terminations;  off-line  quality  channels  are 
not  landline  quality  and  require  operator  interaction  to  provide  interface  between  the 
user  and  NAVCOMPARS.  Typical  operator  interaction  is  visually  proofing  the  message 
for  mistakes  and  correct  format,  and  uien  entering  the  message  into  the 
NAVCOMPARS  using  a  paper  tape  reader.  On-line  channels  are  landline  quality  i  1  and 
interface  directly  with  NAVCOMPARS;  there  is  no  operator  interaction  required. 

Additional  FLTCEN  duties  include  controlling  and  monitoring  Fleet  Broadcast 
channels.  This  control  includes  common,  type,  overload,  and  rerun  channels. 

Hardware  in  the  FLTCEN  includes  VDTs,  teleprinters,  100  word  per  minute 
(WPM)  channels,  and  paper  tape  readers.  (Ref.  8:  pp.  1 1-16] 

4.  Computer  Center  (COMPCEN) 

The  COMPCEN  is  the  location  for  most  of  all  the  automatic  data  processing 
equipment  comprising  the  NAVCOMPARS;  it  also  serves  as  the  interface  between  the 
NAVCOMPARS  and  DCS'  Automatic  Digital  Information  Network  (AUTODIN). 
Responsibilities  include  actual  NAVCOMPARS  operation,  data  base  maintenance,  and 
report  generation. 

Hardware  includes  computer  consoles  to  control  and  monitor  the  entire  system, 
medium-speed  line  printers,  card  readers,  card  punches,  magnetic  tape  stations,  and 
AUTODIN  interface  units.  [Ref.  8:  pp.20-23j 

5.  Technical  Control  (TECHCTL) 

TECHCTL  is  the  master  switchboard  and  monitoring  station  for  the 
NAVCOMPARS.  TECHCTL  uses  landline  or  radiolinks  with  remotely  located 

1 1  Landline  quality  is  defined  as  a  state  where  a  transmission  means  is  of  high  enough  quality 
to  equal  the  performance  received  on  a  land  system  which  is  hardwired. 


transmitting  and  receiving  stations  to  support  the  communication  mission.  Note  that 
TECHCTL  has  no  message  entry  or  delivery  capabilities.  [Ref.  8:  pp.  18-20] 

6.  Receiver  Site  (RECSITE) 

The  RECSITE  serves  as  the  primary  and  secondary  ship/shore  channel  terminal 
area,  using  on-line  channels  from  FLTCEN.  Hardware  is  similar  to  that  of  the 
FLTCEN,  but  also  includes  100  WPM  TTY  on-line  channels.  [Ref.  8:  pp.  11-18] 

7.  Top  Secret  (TS)  Control 

TS  Control  is  the  NAVCOMPARS  area  for  receipt  and  delivery  of  Top 
Secret/ Special  Category  (SPECAT)  traffic.  Using  on-line  and  off-line  processing,  TS 
Control  provides  encryption,  decryption,  and  delivery  services.  Note  that  TS  Control 
may  be  a  SVCEN  function.  [Ref.  8:  pp.23-24] 

8.  Operations  Office  (OPSOFF) 

The  OPSOFF  is  the  central  management  and  control  point  for  functions  ex¬ 
ternal  to  the  actual  NAVCOMPARS;  there  are  no  hardware  interfaces.  Primary  func¬ 
tions  include  report  analysis  (statistical/ historical),  traffic  checks,  and  file  maintenance. 
[Ref.  8:  pp.23-24] 

B.  NAVCOMPARS  SUBSYSTEMS 

When  the  NAVCOMPARS  software  was  originally  designed  it  was  done  with  the 
concept  of  seperating  system  function  into  various  subsystems.  This  concept  of  modu¬ 
larity  meant  that  each  subsystem  was  seperate  with  only  uniform  interface  requirements 
for  intrasubsystem  communication.  The  NAVCOMPARS  subsystems  are:  [Ref.  8:  p.65] 

1.  AUTODIN  Interface  Subsystem  (AIS) 

2.  Executive  Control  Subsystem  (ECS) 

3.  AUTODIN  Control  Subsystem  (ACS) 

4.  Communication  Control  Subsystem  (CCS) 

5.  Receive  Control  Subsystem  (RCS) 

6.  Message  Processing  Subsystem  (MPS) 

7.  Transmniion  Processing  Subsystem  (TPS) 

8.  Transmission  Control  Subsystem  (TCS) 

9.  Support  Program  Subsystem  (SPS) 

10.  System  Service  Subsystem 

See  Figure  32  on  page  70  for  an  illustration  of  NAVCOMPARS  Subsystem  organiza¬ 
tion  [Ref.  8:  p.68j. 


1.  AUTODIN  Interface  Subsystem  (AIS) 

The  AIS  serves  as  the  interface  between  the  NAVCOMPARS  and  the 
AUTODIN  Switching  Center  (ASC).  Primary  duties  are  synchronization  and  error 
checking  of  incoming  data  from  the  ASC.  [Ref.  8:  p.65] 

2.  Executive  Control  Subsystem  (ECS) 

The  ECS  is  the  foundation  for  the  NAVCOMPARS;  ECS  serves  as  the 
hardware/software  interface  for  the  subsystems.  ECS  can  be  divided  into  four  functional 
areas:  console  control,  input/output  (I/O)  control,  porgram  control,  and  interrupt  con¬ 
trol.  [Ref.  8:  pp.65-66] 

3.  AUTODIN  Control  Subsystem  (ACS) 

The  ACS  serves  as  the  interface  for  receipt  and  transmission  of  messages  over 
AUTODIN.  The  interfacing  is  done  between  the  RCS  and  TCS  respectively.  The  type 
of  interfacing  by  the  ACS  is  channel  initialization  and  message  acknowledgement.  [Ref. 
8:  p.70] 

4.  Communication  Control  Subsystem  (CCS) 

The  CCS,  working  with  the  ECS,  provides  both  data  flow  control  and 
logkeeping.  The  CCS  controls  flow  by  queueing  communication  device  interrupts;  ad¬ 
ditionally,  the  CCS  provides  recordkeeping  for  various  input  devices.  [Ref.  8:  p.70] 

5.  Receive  Control  Subsystem  (RCS) 

The  RCS's  primary  duties  include  channel  coordination,  input  buffering,  and 
message  format  exchange.  Channel  coordination  includes  message  sequence  checking 
and  error  checking.  The  RCS  also  controls  input  buffers  for  incoming  data;  incoming 
data  is  later  sent  to  scperate  disk  files  for  processing.  The  RCS  additionally  converts  all 
incoming  messages  into  a  common  code  (EBCDIC)  and  format  for  processing.  [Ref.  8: 
p.71] 

6.  Message  Processing  Subsystem  (MPS) 

The  MPS  performs  the  majority  of  message  processing;  processing  includes 
message  analysis,  format  conversion,  routing  indicator  (RI)  assignment,  distribution  as¬ 
signment,  recalls  and  header  processing.  The  MPS  also  acts  as  an  interface  for  the  sys¬ 
tem  VDTs;  types  of  actions  include  message  recall  requests,  broadcast  screens,  and 
message  editing  and  entry.  [Ref  8:  pp.71-72j 


7.  Transmission  Processing  Subsystem  (TPS) 

Altrouting,  message  journaling,  channel  scheduling,  and  transmission  is  per¬ 
formed  by  the  TPS.  The  TPS  also  interfaces  with  the  MPS  to  give  queue  status;  the  TPS 
also  initiates  and  terminates  message  transmission  with  the  TCS.  [Ref.  8:  pp.72-73] 

8.  Transmission  Control  Subsystem  (TCS) 

The  TCS's  purpose  is  to  transmit  messages  to  an  output  device,  whether  it  is 
communication  channel  or  terminal  channel.  The  TCS  also  performs  any  format  con¬ 
version  necessary  to  utilize  the  output  device.  The  broadcast  rerun  function  is  also 
performed  by  the  TCS.  [Ref.  8:  p.73] 

9.  Support  Program  Subsytem  (SPS) 

Report  generation,  file  maintenance,  and  distribution  assignment  is  performed 
by  the  SPS.  Reports  include  historical  data  on  message  processing,  routing  files,  and 
distribution  files.  [Ref.  8:  pp.73-74] 

10.  System  Service  Subsystem 

The  System  Service  Subsystem  serves  primarily  as  a  utility  program;  it  is  re¬ 
sponsible  for  creating  and  maintaining  the  storage  environment  required  by  the 
NAVCOMPARS.  [Ref.  8:  p.74] 


UJUJIUIIILMUIWMU 


APPENDIX  B.  SIMULATION  MODEL  SPECIFICATIONS 

A.  SIMULATION  MODEL  PROGRAM 
1.  Model  GPSS  Code 

The  following  GPSS  code  is  similar  to  the  code  used  to  run  the  simulations  for 
this  research. 

Test  run  -  #AA/800/25/30/ 1001 


REALLOCATE  COM, 250000, XAC, 5000 
SIMULATE 

INITIAL  XF1,0 

* 

*  DEFINE  FUNCTIONS 

MPREC  FUNCTION  RN1.D3 
.33, 1.0/. 66,2.0/1.0, 3.0 
MLEN  FUNCTION  RN1,C2 

.000,100/1.0,2500 
MZYB  FUNCTION  RN1.D2 

.30,0.0/1.0,1.0 

* 


*  DEFINE  VARIABLES 

* 


PREC  VARIABLE 

FN$ MPREC 

!  ADMIN  VARIABLE 

FN$MZYB 

MSGL  VARIABLE 

FN$MLEN 

TTIM  VARIABLE 

(PF3*8)/75 

PPR  VARIABLE 

PF1-1 

|  *  SIMULATION  PROGRAM 

GENERATE 

108,27, , , ,3PF 

1  ASSIGN 

1,V$PREC,PF 

ASSIGN 

2,V$ADMIN,PF 

ASSIGN 

3,V$MSGL,PF 

!  PRIORITY 

V$PPR 

1  TEST  GE 

XF1,100,RTN 

TEST  E 

PF2,1, ADMIN 

RTN  QUEUE 

QUE,1 

PREEMPT 

OCHNL, PR 

ADVANCE 

V$TTIM 

RETURN 

OCHNL 

1  DEPART 

QUE ,  1 

!  TABULATE 

TPREC 

-  TPREC  TABLE 

PF1 ,0 , 1,5 

TABULATE 

TADMN 

PRECEDENCE  CODE 
ADMIN/OPERATIONAL  CODE 
MESSAGE  LENGTH  (CHARACTER) 
TRANSMISSION  TIME  (SECONDS) 


TRANSACTION  GENERATION 
PRECEDENCE  ASSIGNMENT 
ADMIN/OPERATIONAL  CODE  ASSIGNMENT 
MSG  LENGTH  ASSIGNMENT 
PRECEDENCE  ASSIGNMENT 
INTERCEPT  TRIGGER 
ADMIN  MESSAGE  CHECK 

FACILITY  OCHNL  SEIZED  W/  PREEMPTION 
TRANSMISSION  TIME 
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TADMN  TABLE  PF2, 0,1,4 

SAVE VALUE  1,QM1,XF 
TRANSFER  ,ENDD 

ADMIN  TEST  LE  V$PPR,2,RTN  ADMIN  MESSAGE  PRECEDENCE  CHECK 

QUEUE  RMAD.l  QUEUE  FOR  INTERCEPTED  MESSAGES 

DEPART  RMAD.l 

TRANSFER  ,ENDD 

ENDD  TERMINATE  TRANSACTION  TERMINATION 

GENERATE  3600 
TERMINATE  1 
START  24,, 2 


2.  Model  Functions 

1.  MPREC  -  Message  Precedence  Assignment 

-code:  1.0  -  Routine 
2.0  -  Priority 
3.0  -  Immediate 

-assignment  by  random  number  generation 

2.  MLEN  -  Message  Length  Assignment  (in  characters) 

-continuous  with  low  and  high  end  ranges 
-assignment  by  random  number  generation 

3.  MZYB  -  Message  Type  Assignment 

-code:  0.0  -  administrative 
1.0  -  operational 

-assignment  by  random  number  generation 

B.  SIMULATION  MODEL  FLOW  CHART 

In  Figure  33  on  page  75,  the  single  output  channel  of  the  Fleet  Broadcast  is  con¬ 
ceptualized  as  single  server  queue  model  into  a  general  flow  chart.  Using  this  flow  chart, 
the  general  flowchart  is  further  decomposed  into  GPSS  block  diagrams  in  Figure  34  on 
page  76  and  Figure  35  on  page  77. 


Figure  33.  Simulation  Model  General  Flow  Chart 
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APPENDIX  C.  DECISION  MAKING  AMONG  MULTIPLE  OBJECTIVES 


Many  policy  decisions  today  are  very  complex  with  extensive  interaction  among 
factors.  To  deal  with  these  complex,  unstructured  situations  has  required  the  develop¬ 
ment  of  analytical  processes  to  reach  a  decision  taking  into  account  all  these  interactive 
factors.  Two  such  processes  are: 

1.  Multiattribute  Utility  Analysis 

2.  The  Analytical  Hierarchy  Process 

The  following  sections  provide  a  brief  description  of  each  of  the  processes.  For  a  de¬ 
tailed  description  the  reader  must  refer  to  Ref.  26  and  27. 

A.  MULTIATTRIBUTE  UTILITY  ANALYSIS 

Multiattribute  Utility  Analysis  was  developed  as  a  means  of  allowing  decision  mak¬ 
ers  to  balance  multiple  objectives  while  at  the  same  time  incorporating  personal  judge¬ 
ments.  By  allowing  personal  judgements  the  process  allows  the  inclusion  of  intangibles 
and  preferences;  this  feature  was  lacking  in  earlier  decision  making  processes. 

The  analysis  process  is  composed  of  the  following  four  steps  [Ref  26:  pp.  136-139]: 

1.  Defining  attributes  of  value  -  These  attributes  are  used  to  highlight  the  differences 
between  the  possible  choices. 

2.  Assessing  performance  of  choices  on  each  attributes  -  It  is  at  this  point  where 
perference  is  assessed.  Using  a  set  scale  of  measure,  for  example,  0-100  for  econ¬ 
omy,  choices  are  ranked  in  each  attribute. 

3.  Determining  tradeoffs  across  attributes  -  Using  a  set  of  weights,  decision  makers 
determine  tradeoff  across  attributes. 

4.  Calculating  an  overall  average  -  Using  a  weighted  average,  a  score  is  calculated  for 
each  choice.  The  resultant  overall  value  is  the  choice's  measure  of  attractiveness 
compared  to  the  other  choices. 

B.  THE  ANALYTICAL  HIERARCHY  PROCESS  (AHP) 

AHP  is  based  on  three  principles  which  are  key  to  logical  analysis:  the  principle  of 
constructing  hierarchies,  the  principle  of  establishing  priorities,  and  the  principle  of  log¬ 
ical  consistency.  AHP  consists  of  the  following  steps: 

1.  Using  a  hierarchal  concept,  complex  systems  are  broken  down  into  constituent 
parts  according  to  their  essential  relationships  [Ref  27:  p.33]. 


2.  Step  two  requires  the  establishing  of  priorities.  Using  matrices,  pairwise  compar¬ 
ison  is  performed  in  an  effort  to  find  which  elements  dominate  with  respect  to  cri¬ 
terion  on  higher  levels  of  the  hierarchy. 

3.  Step  two  is  performed  on  all  levels  and  clusters  of  the  hierarchy.  The  end  result  is 
an  overall  priority  vector  for  the  lowest  levels  of  the  hierarchy  [Ref.  27:  p.94). 
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APPENDIX  D.  GLOSSARY  OF  ACRONYMS 


ADM 

Message  Redirect  Command 

AHP 

Analytical  Hierarchy  Process 

ACS 

AUTODIN  Control  Subsystem 

AIS 

AUTODIN  Interface  Subsystem 

ALTROUTE 

Alternate  Route 

AM 

Message  Alternate  Route  Command 

AMSS 

Automatic  Message  Screening  Subsystem 

ASC 

AUTODIN  Switching  Center 

AUTODIN 

Automatic  Digital  Information  Network 

BKS 

Broadcast  Keying  Station 

BSR 

Broadcast  Service  Request 

CCS 

Communication  Control  Subsystem 

CNO 

Chief  of  Naval  Operations 

CMC 

Commander,  Naval  Telecommunications 

Command 

COMM  AREA 

Communications  Area 

COMPCEN 

Computer  Center 

CUDIXS 

Common  User  Digital  Information  Exchange 
System 

CVBG 

Carrier  Battle  Group 

DCS 

Defense  Communications  System 

EASTPAC 

Eastern  Pacific 

ECS 

Executive  Control  Subsystem 

FIFO 

First  in,  First  out 

FLTCEN 

Fleet  Center 

FLTCINC 

Fleet  Commander  in  Chief 

FLTSATCOM 

Fleet  Satellite  Communications  System 

FOTP 

Fleet  Operational  Telecommunications  Program 

FSB 

Fleet  Satellite  Broadcast 

GENSER 

General  Service 

GHZ 

Gigahertz 

:: 


GPSS 

General  Purpose  Simulation  System  V 

HF 

High  Frequency 

HFB 

High  Frequency  Broadcast 

LANT 

Atlantic 

LEASAT 

Leased  Satellite  System 

LRN 

Logical  Reference  Number 

LUF 

Lowest  Useable  Frequency 

MED 

Mediterranean 

MHI 

Message  Handling  Instruction 

MHZ 

Megahertz 

MPS 

Message  Processing  Subsystem 

MPSVC 

Message  Processing  Subsystem  Software 
Module  -  Service  Clerk  Support 

MSGCEN 

Message  Center 

MUF 

Maximum  Useable  Frequency 

MULCAST 

Multichannel  Broadcast 

NAVCAMS 

Naval  Communications  Area  Master  Station 

NAVCOMMSTA 

Naval  Communications  Station 

NAVCOMPARS 

Naval  Communications  Processing 
and  Routing  System 

NAVTELSYSIC 

Naval  Telecommunications  Systems 
Integration  Center 

NCQPROS 

Output  Queue  Profile  Report 

NCQPROT 

Output  Queue  Profile  Report 

NTS 

Naval  Telecommunications  System 

OCR 

Optical  Character  Reader 

OPSIG 

Operating  Signal 

OPSOFF 

Operations  Office 

RCS 

Receive  Control  Subsystem 

RECSITE 

Receiver  Site 

RI 

Routing  Indicator 

SBO 

MPSVC  SVC  Reentry  Command 

SBR 

MPSVC  SVC  Reentry  Command 

SHF 

Super  High  Frequency 

SPECAT 

Special  Category 

SPS 

Support  Program  Subsystem 

SVC 

MPSVC  Command 

SVCEN 

Service  Center 

TECHCTL 

Technical  Control 

TCS 

Transmission  Control  Subsystem 

TPS 

Transmission  Processing  Subsystem 

TS 

Top  Secret 

TTY 

Teletype 

UHF 

Ultra  High  Frequency 

VDT 

Video  Data  Terminal 

WESTPAC 

Western  Pacific 

WPM 

Words  Per  Minute 

ZYB 

Operating  Signal  for  Administrative  Message 
Designation 
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